Przejdź do głównej zawartości

Be a human, not a compiler

A recent reading inspired me to make an observation on programming skills and differences between those the masters and the laymen.

This is not the kind of information you will learn at university or a conference. This can change your professional attitude, so read on.

From the very beginning of our programming education we are talked into thinking like a compiler. We gradually develop the thinking that in order to write a decent piece of code we need to ask ourselves questions like these below:
  • how is this thing going to be evaluated by the computer?
  • will this index ever go out of array boundary?
  • can this variable overflow under any circumstances?
  • will this statement correctly modify / concatenate / process these numbers / strings?
  • is it then this pointer that is going to point at the result when the function returns?
After years of doing that, we are even inclined to judge others at job interviews by how they are able to answer these questions. The funny (and upsetting, at the same time) thing about this is that all of these questions can be answered empirically, by executing a piece of code on a computer. We could use a unit test framework to do this or evaluate the code directly, if we work in an interactive environment.

While I recognize genuine reasons why people think they should turn their compiler mode on while working, I also think there is more value in asking ourselves completely different questions, like these below:

  • does the piece of code I've just written remind me of any of the code smells I read about?
  • will it confuse others when they need to read it or modify it?
  • is there feature of my code that would be error prone to others when they modify it?
  • is my function / method design going to cause, indirectly, code duplication or other code smells in other parts of the codebase?
  • have I covered this piece of code with Unit Tests to the extent that nobody is afraid of modifying it in the future?
  • do I still see a potential for refactoring?
I strongly believe these two sets of questions differentiate the master programmers from the laymen. I believe the master programmers are not afraid to admit they are human beings. They know their code may not be good enough, even though it executes correctly on a computer and passes tests.

I'm not blaming the laymen though - after all that's the attitude that is expected and required of everybody at universities and then when applying for a job and even later when one already has years of experience...

But now you can no longer claim you didn't know. Tomorrow, when you sit at your desk, do something to advance in your professional career: when you write a piece of code, ask yourselves questions from the second list.


Popularne posty z tego bloga

Unit Testing code with IO file operations (in Python)

We may often come across a piece of code that was written without Unit Tests at all. In addition, the piece of code may be dealing with IO like file writing and reading, which makes it more difficult to Unit Test it when we are trying to refactor and modify. Let's suppose the code in question looks like this:

def writeInitialsToFile(filename, name, surname):
    initials = name[0] + '.' + surname[0] + '.'
    with open(filename, 'w') as file:

def readInitials(filename):
    initials = None
    with open(filename, 'r') as file:
        initials = file.readline()
    return initials

A straightforward and bad idea would be to write a couple of Unit Tests that make use of a real file and simply test the reading and writing. Is therea a better way to test this code?

First of all, we need a way to replace the real file with something else. For both reading and writing we will now have a couple of functions, one that expects a stream fo…

Piotr's Less Obvious Advice on Google Mock: State maintenance

Google Mock provides several ways to maintain state inside mock objects. One way of implementing state maintenance is with SaveArg. Consider the following example.

We have a class Configurator, which allows a caller to set and get values of a parameter:

class Configurator

    virtual ~Configurator() {}

    virtual void setParamX(int n) = 0;
    virtual int getParamX() = 0;

And we have a class Client that calls Configurator's methods and it also has a method incParamXBy, that can be used to increase the current value of paramX by a certain value.

class Client

    Client(Configurator & cfg);
    virtual ~Client() {}

    void setParamX(int n);
    void incParamXBy(int n);
    int getParamX();


    Configurator & _cfg;

incParamXBy internally calls setParamX and getParamX on Configurator:

void Client::incParamXBy(int n)
    _cfg.setParamX(_cfg.getParamX() + n);

Let's assume that the initial value of paramX is A and that we want to increase paramX by…

Piotr's Less Obvious Advice on Google Mock: Returning new objects from a mock

Google Mock provides a way to return newly created objects from a mock method. Suppose we have a  Generator class that is supposed to generate new objects when createNewRecord method is called:

class Generator
    virtual ~Generator() {}
    virtual Record * createNewRecord() = 0;

...and suppose we want to mock this class:

class MockGenerator : public Generator
    MOCK_METHOD0(createNewRecord, Record * ());

Suppose the caller class Client has run method defined as follows:

void Client::run()
    for(int i = 0; i < 3; i++)
        rec_tab[i] = gen.createNewRecord();

We want the mock to return a pointer to a new object each time createNewRecord is called. This is how we can express this in the test code:

TEST(ClientTest, CanRun)
    MockGenerator gen;
    Client c(gen);

    EXPECT_CALL(gen, createNewRecord())
                 //this is equivalent of returning new Record(1,2,3)