Your one stop shop for the cause of all coding horrors

Started by
36 comments, last by Juliean 10 years ago

You gotta see this article:

http://blog.codinghorror.com/new-programming-jargon/

The keyword I was looking for in my shorthand post was "refuctoring".

It could be that I am just a "Jimmy"

I kinda like the "Smurf Naming Convention" though. haha.

They call me the Tutorial Doctor.

Advertisement

My personal project right now is a world conquest game that has various source files for rendering the globe. The internal name of the project (i.e. the one I use in code, not the one it will release under) is Globo.

I think of that Smurf Naming thing every time I type: #include "Globe/Globo_Globe.h"

Nice article, i personally hate with passion the "Yoda Conditions".

ex: if(5 == count)

"Heisenbug"

yeah, those are annoying...

like, bug which is annoyingly hard to recreate and occurs rarely, may appear only when not run in a debugger, or when the code is stopped/single-stepped there is no evidence of the bug's existence... (ex: program runs with a bug, set a break-point, single-step, and everything works as intended...).

may sometimes be due to "spooky action at a distance", like (off somewhere in some distant part of the program) instead of writing "foo[x*y+z]=...;" one wrote "foo[x*y*z]=...;" which may otherwise go largely unnoticed if it fails to land on an unused memory address (may be very common for programs where most of the address space is in-use).

may be also be called "dude, where's my RAM?" if it also results in an intermittent memory leak.

I have to admit, the Egyptian brackets do annoy me. But then, lower-cased first letters of functions names annoyed me, but now I prefer it that way. So did underscores in variable names.

They call me the Tutorial Doctor.


Egyptian brackets do annoy me

I prefer Egyptian brackets because it eats less lines. Indents give enough information what is inside which block so I don't need brackets to tell me same thing.


function EgyptianizeTheBracket(){
    looks missing;
}

function UnEgyptianizeTheBracket()
     { for short lines;}

function UnEgyptianizeTheBracket()
     {
     for longer lines;
     }

Good point Zaoshi. I just think that having them on the next line shows the start and end of the code inside the function. Along with indentation it just looks neater.

They call me the Tutorial Doctor.

I've been using Egyptian brackets for a long time, so I read indentation, not brackets. When I have to read code based on brackets instead of indents it's too hard for me (luckily VS2013 has autoformatting!).

I love egyptian brackets but not everywhere, i think they are most fitted for ifs and while/for loops. Function and switch should use normal brackets style.


void Function()
{
    if(x == 1){

    }

    for(;;){

    }

    switch(x)
    {
    case 0: ...
    }
}

Nice article, i personally hate with passion the "Yoda Conditions".

ex: if(5 == count)

There is a reason for these. They throw errors at compile time if you try assigning improperly (for instance forgetting your second "==").

This topic is closed to new replies.

Advertisement