What are your programming idiosyncrasies? [closed]

Question

I noticed that I have a peculiar habit of finishing every line with a space. It carries over from my prose writing where a paragraph can have multiple sentences and so it is very common to follow a period with a space, and I end up doing that automatically for every period (or when it comes to programming- semicolon). It started out as something automatic, but I'm so used to this by now that if I miss the space it actually bothers me and I end up returning to that line to input it.

What are some of your programming idiosyncrasies?

EDIT: When I wrote this I was as student. After going through code reviews at work I no longer do this.

Answer 1

• Removing unnecessary white space - usually extra blank lines people leave in code
• Removing commented out code - that's what source control is for (though I am a hypocrite on this sometimes)
• "Tidying" if statements - I prefer if (expression) over if( expression ) etc.

The problem with all this is that my actual edit can get lost in all the "noise". I try to keep this to a minimum.

Answer 2

Atleast two Ctrl+S's to make sure it's saved.

Answer 3

When other people give me code, if it's just short snippets, I have to go through and do a little reformatting to fit my personal style preferences before I'm able to look at what they're doing.

It also irks me when I'm helping people with something and their style is almost nonexistent.

Answer 4

I can't stand 'backwards' comparisons to constants:

"blue".isEqual(colorName);

versus

colorName.isEqual("blue");

I realize both are fine but the latter just feels right and the former makes me angry.

I also can't stand overly obvious commenting as well as worthless variable names.

//Set the flag
myFlag = true;

Answer 5

I am quite OCD about needing to remove any white spaces at the ends of lines. The worst is if a blank line has been left made up of spaces to match the current indentation. I always turn on the 'show white spaces' option on my IDE so that I can see them easily. I know that they have no impact on the code but I just need to get rid of them all.

Answer 6

My biggest idiosyncrasy is probably descriptive (and perhaps overly so to some) variable names. I would much rather see/read customerName in lieu of c_name, etc.

Answer 7

I may sound like a house wife, but I want documentation and code to be as clean as possible.

Answer 8

A friend of mine has a habit of putting Here be dragons! in a method's comments block if the code is a bit of a hack.

It seems he is not alone.

Have a look at a google code search for be dragons.

Just found this in thrunderbird.

To pop it up: Tools -> Options -> Advanced tab -> General tab -> Config Editor

Origin:

"Here be dragons" is a phrase used to denote dangerous or unexplored territories, in imitation of the medieval practice of putting sea serpents and other mythological creatures in blank areas of maps.

The only known historical use of this phrase is in the Latin form "HC SVNT DRACONES" on the Lenox Globe (ca. 1503-07). Earlier maps contain a variety of references to mythical and real creatures, but the Lenox Globe is the only known surviving map to bear this phrase.

Answer 9

Everywhere I see conditional or looping constructs not enclosed in curly braces (or the VB or Delphi equivalents), I gotta put them in, as such:

if (someCondition) continue;

becomes

if (someCondition)
{
    continue;
}

Sure, I've burned approximately 11 more characters, but I feel I've saved some time/grief in the future when an enhancement calls for something to happen before the continue;.

Answer 10

I have a few I guess...

Similar to TomWij's, I write pseudocode out for non-trivial steps out as comments. I keep it short, clean, simple, and generally numbered (starting from 1 to x). It also tends to serve as documentation. Then I write the actual code to follow under each step. The more non-trivial it is, the more likely I'll keep it to help myself and future developers know what it's supposed to do.

I also tend to use foo and bar as dummy naming variables for quick programming proof of concepts. If both are already used within the scope, I get creative and go with foofoo and barbar, or foo1 and bar2 etc. The bad part is I sometimes forget to rename properly them and it gets checked into version control.

Answer 11

In SQL I write columns out like:

SELECT    Column1
     ,    Column2
     ,    Column3
     ,    Column4
FROM TABLE

It's carried over into how I call/define methods with lots of parameters:

function( param1
        , param2
        , param3
        , ... )

Answer 12

I can't force myselt to start writing in a new block if it is not surrounded with braces (or end keyword is missing if I'm coding in Ruby). For example:

def foo(bar)
  # I'm feeling "insecure" here

but

def foo(bar)
  # Now everything is OK!
end

Answer 13

I tend to put some funny commented lines into my code as an easter egg like the one you can find if you search through the wordpress source code. In one file you find:

// Silence is golden.

Answer 14

By convention, most Delphi code is indented 2 spaces per level. I tend to indent mine by 3 spaces because I find that easier to line up with my eyes.

Answer 15

I have a few that rank right up there with others.

• I always make sure that I have comments on code blocks, and I'm not afraid to write inline comments and get frustrated when complicated pieces of maintenance code doesn't have comments
• Commented out code needs to leave, quickly, and not leave a forwarding address. (That's what source control is for)
• I hate inconsistent spacing between regions and blocks of code, there must be a single line space so that if collapsed within Visual Studio the little Region boxes do not run into each other.
• I cannot stand variables named i, x, y, z, foo, bar, etc unless used for a counter, any other use gets changed.

Answer 16

I REALLY like parentheses.

{ :( } ( :) )

Answer 17

Despite having a monitor that has a 1680x1050 resolution (yay!) and a coding standard that states we must have line widths of less than 100 characters, I still code to 78 characters where I can.

Hey, 78 is less than 100, so technically it's allowed...

Answer 18

When writing long strings or cases for switch() statements and in various languages:

stream <<"Text is delicious. "<< varA <<" Indeed, oh so delicious. " << varB
           <<"Text is delicious. "<< varC <<" Indeed, oh so delicious. " << varD
           <<"Text is delicious. "<< varE <<" Indeed, oh so delicious. " << varF;

string = "Text is delicious. "+ varA +" Indeed, oh so delicious. "+ varB
           +"Text is delicious. "+ varC +" Indeed, oh so delicious. " + varD
           +"Text is delicious. "+ varE +" Indeed, oh so delicious. " + varF;

string = "Text is delicious. ". varA ." Indeed, oh so delicious. ". varB
           ."Text is delicious. ". varC ." Indeed, oh so delicious. " . varD
           ."Text is delicious. ". varE ." Indeed, oh so delicious. " . varF;

The same style applies to any other long 'one-liners'. I also especially have a habit of condensing some function calls when they are very short usually.

/* Formula Description */
int soFunctional(int a, int b){ int c=a; a+=b*b/2; b=c*b; return a+b; }

Whether nested or not

if or loop(condition)
{
    ...
    ...
    ...
}

Unless it is one statement, then usually

if(condition) statement();
if(condition)
    var= statement + many * operations / with +(long % lines());

Finally I often will create classes like:

class _object_
{
    ....
};

_object_ OBJECT;
typedef _object_ object; //sometimes

Where OBJECT is a special case of _object_ sometimes I'll use main, root or default instead of the object's name and sometimes I'll use all of them.

When I skip two, three or four lines, I feel like I'm setting a narrative. Very compulsive.

Naming scheme is somewhat crazy. Temporary variables of sufficient "obviousness" will often be named such things as "taco" "dumb" "monkey" during alpha phase. Most of my code is made so that I can easily do a search and replace on the whole file without worries, for when I'm actually sharing the code later!

At that point the naming takes on a life of it's own. One thing I notice is that usually I will say VariableName whereas I usually see variableName.

If VariableName looks wrong I'll go to Overly_Descriptive_Variable_Name. Usually all my variables except for ones like x,y,z,i and sometimes num will be fairly long. About,... 7-12 characters.

Answer 19

I find open curly on a new line irritating. it should be in the same line as the conditional statement.

Also, I find green text over black background in vim too depressing. Black over grey is better.

Answer 20

It bothers me to try to read/work with long functions. I detest scrolling so when someone writes a function that is long (usually 75 lines or more where it's longer than my screen size) I simple can't leave it along without doing refactor -> extract method. If the function has a very large loop or conditional in it, there is no way I can fight off the urge to break it up.

Answer 21

Whenever I see this:

if (var == 2)

I cannot stop myself from re-writing it as

if (2 == var)

When I was learning to program (with Ada) I made the mistake of mixing up an assignment operator with an equality test and ever since my programming style would make Yoda happy.