Basic C++ Coding Patterns

I just got a response from a possible employer that they didn't want to move forward due to "...line by line code decisions are odd per basic C++ coding patterns...". I'm trying to figure out exactly what concepts they might be referring to and was hoping others might some ideas of what that means to better hone in on what to improve on.
Based on the quote you gave, I can only surmise that he was referring to code that made decisions in a very "linear" pattern like (for example):

Let's say I'm creating a program that both controls a robot AND keeps track of its activities. The robot can move, cook and clean. (Let's keep it simple). Each time the robot performs one of these activities, the program will react differently based on the activity being performed.

For example, if the robot is walking, the program will display the battery life, number of steps taken, etc...

What I could do is create a list of if-else statements that test the robot's current activity and activates the required response.

The problem with this line-by-line code decision style is that:
a) It makes your code messy, eventually. You'd have to keep adding if-else statements that would take up an enormous chunk of code space in your source. Makes debugging harder and the code very difficult to read and error prone.

b) It's hard to extend. What if you wanted the program to do multiple things when it observed that the robot was walking? For example, if the robot walked, then the program would then have to display the status information, update the owner's smartphone to indicate what is being done, deactivate the security alarm in the owner's house so that it doesn't go off, etc...?

Because we're using if-else statements, we'd have to locate the correct if-else block, add in the desired code (which would potentially involve adding more if-else blocks) and at the same time make the whole program more convoluted.

The C++ coding pattern to solve this problem would be the "Observer Design Pattern":

Basically, you create 2 classes. One models the robot class and its activities (Walk, Cook and Clean would be methods). It would also contain a list of "Observers" - more on that in a moment - which it will Notify when any of its activities are called.

The second class is the Observer that in its simplest form contains an Update method. This update method would contain the code for the specific task.

The beauty of this design pattern is that you can create as many Observers as you'd like for each of the robot's methods. You add them to the Robot's list of Observers and that's all.

When the Robot's Walk method is called, that method will notify all of its Observers in the list and each Observer will react accordingly.

Doing it this way using OOP principles makes the program more easy to understand, shorter and provides room for extensibility.

That's my take on it. If you read the link I gave you (I found it on the web a while back) it does a good job of quickly giving you an example of an Observer Design pattern.

Hope that helps,

Last edited on
Can you post the code that the prospective employer rejected? Rather than guessing what was meant, we could give more specific suggestions about your coding style that would make you a better candidate for employment.

There are lots of little habits we all get into when we are novices that we may or may not correct as we mature as coders. These could be things like cutting and pasting code rather than writing separate functions, passing lots of related data into related functions rather than writing a class, spaghetti code, lack of white space (making it hard to read), lack of comments, or poor choice of variable names. The response you got from the prospective employer could be merely a polite, ambiguous way of saying your coding style sucks. (I have no way of knowing one way or the other--I'm just offering this as a possibility.)

When you work in a team, your code will be reviewed by others, and the team will probably ask you to follow some defined coding standards. They may feel that whatever you sent them is so far from their standards that it will take too much effort to break you of your habits.

Don't fear. You can learn better coding style with practice. Like I suggested earlier, find someplace to post some of your code and ask for comments. You will get a maelstrom of comments from denizens here, some even contradicting each other. You may get lost in religious wars about whether the opening "{" should be at the end of one line or at the beginning of the next line, and things like that. Just be consistent in your own code and ignore those comments for now--an employer will tell you what is wanted.

However, if you look in the comments for themes of structural significance--program flow, class design, encapsulation, function design, code readability, etc., you will learn tips in code design and implementation. Practice them, and you will have more robust code ready for the next potential employer.

A lot of us have a lot of experience, and we can give hints into what companies may be looking for.
Topic archived. No new replies allowed.