Eccentric Coding Habits -- got any?

I was just wondering how many of you recognise your own coding style from odd little habits you've accumulated.

One of my oddities is that I don't like using the ! operator in if statements (I'm paranoid that it will get mis-read when scanning the code later) so I always write my if statements out in full:

if(check == true)
instead of
if(check)

and

if(check == false)
instead of
if(!check)

So if I look at code from group projects, I can always tell what's mine.
So what about you, so you have any little oddities that mark code as recognisably yours?

Herbie

Dr Herbie wrote:

I was just wondering how many of you recognise your own coding style from odd little habits you've accumulated.

One of my oddities is that I don't like using the ! operator in if statements (I'm paranoid that it will get mis-read when scanning the code later) so I always write my if statements out in full:

if(check == true)
instead of
if(check)

and

if(check == false)
instead of
if(!check)

So if I look at code from group projects, I can always tell what's mine.
So what about you, so you have any little oddities that mark code as recognisably yours?

Herbie

Its kind of like VB...

I do not write my one-line if-statements (in C#) with {}

deafult:
if (check)
{
   Method();
}

my style:
if (check)
   Method();

or sometimes even just
if (check) Method();

I dunno why..  but for ages I kept spelling length wrong..
I'd do something like:

if (firstName.lenght > 0) {

}

silly, I know..  but I've gotten over it

I can usually tell my code from my peers because it is formatted correctly and I spell things correctly. The worst offenders seem to be DBAs writing TSQL, the spacing is never consistent and sometimes they upper case their keywords and other times not (usually within the same query).

When looking at someone else's code, I usually correct their crappy formatting so that I can comprehend their code easier.

Anyone else run into sloppy formatters?

I'm a fan of small functions. I will always try to refactor my functions so that blocks of code turn into smaller functions. It makes my code more readable and it basically make comments useless because you can litterally read the code. Might not be optimal speed-wise, but I'll take code that's easier to read over code that executes faster anytime I can. Unless of course speed is critical to the application being written!

resist wrote:

I'm a fan of small functions. I will always try to refactor my functions so that blocks of code turn into smaller functions. It makes my code more readable and it basically make comments useless because you can litterally read the code. Might not be optimal speed-wise, but I'll take code that's easier to read over code that executes faster anytime I can. Unless of course speed is critical to the application being written!

Take a look at XP and the Single Responsibility Principle.

http://davidhayden.com/blog/dave/archive/2005/05/29/1066.aspx

Antitorgo wrote:

I can usually tell my code from my peers because it is formatted correctly and I spell things correctly. The worst offenders seem to be DBAs writing TSQL, the spacing is never consistent and sometimes they upper case their keywords and other times not (usually within the same query).

When looking at someone else's code, I usually correct their crappy formatting so that I can comprehend their code easier.

Anyone else run into sloppy formatters?

I'm a developer/DBA as well, and you mentioning T-SQL made me remember that I have a *very* specific set of standards in my mind that I use when I write T-SQL.  Everything from the way that different blocks are tabbed to capitalization, to where line breaks go, I have an unwritten rule for.  Like you, I can hardly read T-SQL without first recasing and reformatting it.

I would love to find a customizable formatter for T-SQL that I could configure to transform code into my format.  Any ideas?

I just love the new ?? operator. Great for providing default values, or for lazy-loading objects:

XmlSerializer fSerializer;
public XmlSerializer Serializer
{ get {
   return fSerializer 
         ?? (fSerializer = new XmlSerializer(GetType()));
} }

TommyCarlier wrote:



I just love the new ?? operator. Great for providing default values, or for lazy-loading objects:

XmlSerializer fSerializer;
public XmlSerializer Serializer
{ get {
   return fSerializer 
         ?? (fSerializer = new XmlSerializer(GetType()));
} }

What does it do?

if is null?

jmbledsoe wrote:


I would love to find a customizable formatter for T-SQL that I could configure to transform code into my format.  Any ideas?

ApexSQL - expensive, but very cool... I've been playing with the free version of SQLPrompt from RedGate too, it is cool because it "plugs" into Visual Studio and does the intellisense and auto capitalizes keywords as you type them... Only thing with SQLPrompt is it isn't as configurable as I want.

jmbledsoe wrote:


I'm a developer/DBA as well, and you mentioning T-SQL made me remember that I have a *very* specific set of standards in my mind that I use when I write T-SQL.  Everything from the way that different blocks are tabbed to capitalization, to where line breaks go, I have an unwritten rule for.  Like you, I can hardly read T-SQL without first recasing and reformatting it.

Actually, this made me think...

One thing that bugs me is people putting AND at the end of the previous line, I put mine at the beginning of the new line:

Ex:
where foo=bar and mydate<>'1/1/2001'
vs.
WHERE
   foo = bar
   AND myDate <> '1/1/2001'

This way I can easily comment out the subsequent lines of the where clause with a --

Only problem is that if I want to remove the first expression in the where clause it all goes out the window, but I find that because I usually have important stuff as my first expression in the where clause that I rarely comment it out...

Oh, and another pet peeve, looking at the above code is people who don't put spaces between the = sign! Ugh.

I can usually tell my code from my co-workers because its formatted... has a consistant use of varaible names that are (OMG!!) meaningful (usually).... I'm also a fan of encapsulating anything that i do or could do more than once....

When I write SQL, column names match DB column names in exact case and all SQL keywords are in all caps.... (so much easier to read).....

I comment code incesantly along with explanations things like ('StringBuilder is faster than concatenation for long operations) and stuff like that.... ohh and silly comments like ('Ok now clean up after yourself...its only polite)

for long comments I do the goofy:

'++++++++++++++++++++++++++
' this is a long comment
'++++++++++++++++++++++++++



thaz about all i can think of that allow me to find my own code

Ang3lFir3 wrote:

for long comments I do the goofy:

'++++++++++++++++++++++++++
' this is a long comment
'++++++++++++++++++++++++++



thaz about all i can think of that allow me to find my own code

I hardly ever use "long comments", I commentate on how the flow works. That's probably a bad idea if I reimplement it as something else.

When I'm splitting up methods/functions into sections, I use this type of comment:

//////////////////////////////////
// Section Name
/////////////////////////////////

Works fine for me

I also always use braces in control statements/language constructs, because I like to be explicit, but also because I've forgotten the syntax for the "one-liners".

Instead of doing:

if(someVariable == null)
{
     DoSomething();
}

I write:
if(null == someVariable)
{
     DoSomething();
}

And I always write defensive code which many developers
don't do anymore for some strange reason.

Ilya

ilya wrote:



And I always write defensive code which many developers
don't do anymore for some strange reason.

My guess would be that people rarely use C/C++ where that would be an issue. In most cases, the compiler catches this stuff... Although in Java I'd often to:

if ("Foo".Equals(myStr))

vs.

if (myStr.Equals("Foo"))

for the obvious reasons.

Antitorgo wrote:


Actually, this made me think...

One thing that bugs me is people putting AND at the end of the previous line, I put mine at the beginning of the new line:

Ex:
where foo=bar and mydate<>'1/1/2001'
vs.
WHERE
   foo = bar
   AND myDate <> '1/1/2001'

This way I can easily comment out the subsequent lines of the where clause with a --

Only problem is that if I want to remove the first expression in the where clause it all goes out the window, but I find that because I usually have important stuff as my first expression in the where clause that I rarely comment it out...

I write WHERE clauses like this:
WHERE
   foo = bar
AND 
   myDate <> '1/1/2001'

Seperating the AND allows me to comment (like you said) the first and the second expressions. Usually there is no real importance in the order of expressions (especially when sql is autogenerated), so the first one is a candidate for comments just like the second.

Rotem

Most devs write:
int i = 0;
string = "blah";
double d = 10.0d;
float f = 1.0;

I write something like this instead:
Int32 i = 0;
String = "blah";
Double d = 10.0d;
Single f = 1.0;

Sheva

1)  I use "this." for everything that can use it. Maybe intellisense, maybe not, I just do this.StuffRegardless(); At least it shows scope...


2)  string someString = String.Empty;

I always use the above and not  = "";
I always use the String and not string class, too, and I forget why...


3)  I also use 'Environment.NewLine' instead of "\n" or "\r\n".


2 & 3 may be fairly mainstream for many devs... I don't know.