an industry coding standard?

Dev Shed Forums Sponsor:

May 8th, 2004, 12:36 AM

vb.net

Demonic Swordsman DGQB

Join Date: Apr 2003

Posts: 1,009

Time spent in forums: 3 Days 14 h 42 m 21 sec
Reputation Power: 77

an industry coding standard?

Just noticed an interesting coding pattern by many professionals - when instantiating a new object and calling the class constructor, the parameters are usually not declared prior. For example in C#, to declare a new Sqlcommand, I personally would (vs what others I've seen would) usually create the SQL string and connection object first:

Code:

string sql = "select * from table";
Sqlconnection conn = new Sqlconnection(...);

then, the Command:

Code:

Sqlcommand cmd = new Sqlcommand(sql, conn);

However, professionals seem to do it all on one line:

Code:

Sqlcommand cmd = new Sqlcommand("select * from table", new Sqlconnection(...));

I've been told the latter is the preferred coding standard in enterprise application development, but I am not sure why. It seems harder to debug, and I don't see any advantage except fewer lines to maintain. Can some light be shed?

May 8th, 2004, 06:47 PM

DevCoach

Contributing User

Join Date: Feb 2004

Location: London, England

Posts: 1,254

Time spent in forums: 1 Week 6 Days 8 h 10 m 34 sec
Reputation Power: 265

I don't think there is an "industry standard" either way. Individual organisations may have their own internal coding standard, but I have never seen a coding standard that covers this issue.

There are pros and cons for both ways of doing it...

Advantages of splitting it across separate lines:

* easier to debug - you can set a breakpoint on the individual lines and inspect the effect of running each line.

* arguably easier to read, especially for novices since the lines are shorter and less cluttered

* a well named temporary variable can help a lot in explaining the code

* you can easily move all the SQL statements into a single place - it is generally considered bad practice to have text strings scattered throughout your code

Advantages of having everything inline:

* you do not need to create lots of named temporary variables. This has several implications:

* you dont have to think up lots of names

* it is obvious that the temporary is only used in that one place. If you name it, then you have to search through the code to see if it is used anywhere else.

* it can be garbage collected at the end of the line, instead of at the end of the method.

* temporary variables can get in the way of refactoring the code

I tend to bend either way - I often inline a lot of code initially, then refactor it onto separate lines if I think it makes the code clearer, or if I need to debug the code.

The book "Refactoring" by Martin Fowler (which should be compulsory reading for developers) has a number of refactorings that address this issue - 'Inline Temp', 'Replace Temp With Query', 'Introduce Explaining Variable'. Read the book, or go to the refactoring web site for more information.

The important point is that code is highly maleable - whichever way you do it initially, it should be easy to change in the future.

Dave - The Developers' Coach

May 9th, 2004, 12:44 PM

dejaone

Contributing User

Join Date: Mar 2004

Posts: 300

Time spent in forums: 8 h 7 m 22 sec
Reputation Power: 5

that's not industry standard, just prefrences for easy maintainance, readability and flexibility.

May 10th, 2004, 01:30 PM

dog135

Doggie

Join Date: Jul 2003

Location: Seattle, WA

Posts: 751

Time spent in forums: 10 h 38 m 25 sec
Reputation Power: 7

Whenever I can, I tend to eliminate all my temp vars whenever possible. It helps give the compiler a little more control on optimizing the code.

I especially try to avoid lines like:

Code:

short getit(long x){
	byte y,z;
	short r;
	y=mem[x];
	z=mem[x+1];
	r=(y<<8)+z;
	return r;
}

I see code like that at work and it drives me crazy.

To me, this is much more readable: (and probably faster)

Code:

short getit(long x){
	return (mem[x]<<8)+mem[x+1];
}

In the first example, you have to search around for what the variables contain. (esp. if they're not labeled well) In the second one, the whole equation is understandable at a glance.

However, I almost always define and declare my variables on different lines, rather then the same one. I like all my variable names in one place that's easy to search through. It also doesn't effect optimization doing it that way.

__________________
"Science is constructed of facts as a house is of stones. But a collection of facts is no more a science than a heap of stones is a house." - Henri Poincare

May 10th, 2004, 07:00 PM

DevCoach

Contributing User

Join Date: Feb 2004

Location: London, England

Posts: 1,254

Time spent in forums: 1 Week 6 Days 8 h 10 m 34 sec
Reputation Power: 265

Quote:

Originally Posted by dog135

However, I almost always define and declare my variables on different lines, rather then the same one. I like all my variable names in one place that's easy to search through. It also doesn't effect optimization doing it that way.

I *always* initialise variables at the point that they are declared - I have been caught out too many times in the past by accidentally using uninitialised variables that contain random values and produce wierd results (in C & C++). I am also used to using scripting languages such as Python and Perl, where you create a variable by assigning to it, so it feels far more natural to me that declaration and initialisation go together.

The practice of having all the variables defined at the start of a function or block of code stems from archaic languages like C and Pascal which required it for the convenience of the compiler, rather that the convenience of the programmer. It is now widely accepted that defining variables at the point that they are first needed makes the code more readable and easier to refactor.

Dave - The Developers' Coach

May 10th, 2004, 08:31 PM

dog135

Doggie

Join Date: Jul 2003

Location: Seattle, WA

Posts: 751

Time spent in forums: 10 h 38 m 25 sec
Reputation Power: 7

Quote:

Originally Posted by DevCoach

...I am also used to using scripting languages such as Python and Perl, where you create a variable by assigning to it, so it feels far more natural to me that declaration and initialisation go together.

The practice of having all the variables defined at the start of a function or block of code stems from archaic languages like C and Pascal which required it for the convenience of the compiler, rather that the convenience of the programmer. It is now widely accepted that defining variables at the point that they are first needed makes the code more readable and easier to refactor.

Perl:

Code:

use strict; # force variable definitions
my ($name,$id);

$name="bob";
$id=42;

Besides, I personally like seeing all the variable names all in one place. It gives you a quick glance at what's going on in the function.

Seeing a function that starts like:

Code:

double cdis(double x, double y, double z){
	double xrot,yrot,zrot,dist;
	...
}

gives you an idea about what's going on, even though the name and parameters aren't very informative.

Thread Tools	Search this Thread
Email this Page	Search this Thread: Advanced Search
Display Modes	Rate This Thread
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode	Rate This Thread: