What Workplace Coding Practices Do You Use?

Agent_9191 asks: "Recently I've been promoted to what essentially amounts to a project lead role for every project we do, in house. Since my company has run for the past 35+ years with no form of central IT department, there has been no standards put into place for developers to abide by. One of my tasks is to set up standards in how projects will be implemented and produced. Right now I'm more concerned about trying to set up coding standards, so that any developer can jump into any part of a project and be able to figure out what's going on, without wasting a couple hours just to figure out the code. I've come across some documents in this area from a few sources (of course can't remember them off the top of my head). What practices/standards do you use in your workplace?"

My boss doesn't care

[b0lt]

I like to think of it as "don't ask, don't tell" :D

Standards

[zutroy]

For every conditional, you chug a beer.
For every loop, you chug a beer.

And, of course, for every save, you do a shot of tequila.

Standardize on a good language.

[Anonymous Coward]

The importance of a single language standard can't be overstated. Ever since my company switched to LOGO I can understand my co-workers' code at a glance.

One Solution

[Anonymous Coward]

Outsource them all.

WHAT Standards?

[thepropain]

I'm all self-taught, so I have my own style which others tell me is impossible to make heads or tails of. The standard is: the boss promises stuff to our clients, and I have to whip it out [snicker] as fast as possible. Doesn't leave much time to make easy on those who would come after me. I jokingly call the mess of code I have to make JOB SECURITY.

Standards

[shoemakc]

Yeah, standards are great.....we've got lots of them :-)

-Chris

Re:Standards

[blank89]

int beersOnTheWall = 99;
while(beersOnTheWall>0) {
   me.chugBeer();
   beersOnTheWall--;
   System.out.println(beersOnTheWall + " bottles of beer on the wall...");
   }

Dilbert

[RedNovember]

heh [unitedmedia.com]

Never comment!

[Billly Gates]

Its for wussies!

-USe tons and tons of goto statements.

-Make sure you use particular letters capped for variables of different types to make them more confusing for the losers who can't read the code and remember what each one was.

- always make calls by reference using pointers as arguments. Don't use call by values.

- Hell user other pointers that use other pointers to make things more interesting. Reassign them all over the place

- Never use a three tier model when developing client/server apps. This only creates redundancy and gets in the way of solving the problem.

- When linking to a database always use vendor specific extensions and avoid a database layer using something like odbc. It makes use of the advanced feature set by the particular RDBMS.

- Be a man! Show how much you know perl. Alot of one linners can save tons of time with exotic line switches

Oh last... make tons of money and gain job security because no one in Earth will be able to understand or work on your projects after doing all of these things. Enjoy

Re:What a question!

[chromatic]

Perhaps someone broke in and fixed the code.

Even better: CPAMAP

[gerf]

(copy paste as much as possible)

Re:Comments

[iabervon]

I prefer:

if x==456 then //checks to see if x is equal to 256. If it is, then the code within is executed

That way, there's less chance for confusion if the code gets modified in the future.

Re:Comments

[multipartmixed]

Out of curiosity, what kind of platforms do you code for? Even my commodore 64 had 16-bit ints.

Magic Numbers

[Anonymous Coward]

Magic numbers are the worst thing you could ever put into code. They are even worse than hungarian notation...

Re:Comments

[lbernba]

did you notice that the comment does not match the code?
or is there some spot in the universe where x==456 will check to see if x is equal to 256?

Re:Comments

[Hognoxious]

Er, like WHOOOSH or something.

Re:Comments

[swillden]

if (x == 456) { // Check if step motor reached final position. If yes, halt motor, otherwise step

That line still contains an example of one of my biggest pet peeves... the use of magic numbers. Okay, so the comment explains what 456 is, but not why and makes no provision for managing changes. What if a new design had a stepper motor whose final position was 256?

Magic numbers are a reality, of course, especially when dealing with hardware. But if there's no way for the code to dynamically determine the values, the very least you can do is to define a symbolic constant, and collect the constant definitions together in one place. For example:

#define FOUR_HUNDRED_FIFTY_SIX 456

// ...

if (x == FOUR_HUNDRED_FIFTY_SIX) { // Check if step motor reached final position

See how much better that is? And if the value changed to, say 100, all you have to do is modify the constant definition in one place, like:

#define FOUR_HUNDRED_FIFTY_SIX 100

Really, a little extra work up front goes a long way.

Re:Comments

[el cisne]

HA!!! YOU were the guy who wrote this code I am having to work on now!!! ;-)

Re:Comments

[roystgnr]

Even for a novice programmer, code like if(x == 456) is self-explanatory, no comments are needed.

You're right - how could it be possible not to know what that code is doing? (The rule is, the only magic numbers allowed are -1, 0, and 1. 456 is right out.)

Okay, but that's going to get really hard to debug!

if (x == (1+1)*(1+1+1+1)*((1+1+1+1)*(1+1+1+1)*(1+1+1+1)-(1+ 1+1+1+1+1+1)))

Our process

[I Like Pudding]

If it compiles, ship it. If it doesn't compile, ship it. If the users complain, ignore them (they are always complaining). If the users complain moreso than normal, work all day and night and fight with QA and the admins and the VPs to get a patch in.

Repeat until app becomes unmaintainable. Repeat furthur. Repeat.

I will be giving seminars on how to implement Sisyphusian Unified Process throughout the year down at the bar. If I happen to be unconcious, please leave me be - that's my "comp time".

Coding standards

[Todd Knarr]

As someone with 20+ years of professional programming under my belt, a lot of it doing maintenance and enhancement of existing code, I'll say this: most of what's considered "coding standards" doesn't much matter. Indentation, brace positioning, type prefixes on variables, underlines vs. StudlyCaps, capitalization in general, most competent programmers can pick up on any variation quickly. The few things that count are more general:

1. Comment logic and motivation, not the code itself. I can figure out what the code's doing. What I need coming into it's what it's supposed to be doing, why the code does things the way it does, what the data structures are supposed to represent and how they're supposed to be used. On routines, tell me what the routine's supposed to accomplish, what arguments it takes in and what results it spits out (including error conditions).
2. Make variable names descriptive. Abbreviate where it makes sense, but make the name give me an idea of what it's for. It's less important that I know it's a string than that I know it's the last name of the customer whose order you're processing. And if all it's for is the index in a loop and it's got no meaning outside of the loop, then yes i and j are perfectly legitimate names that any programmer will (or should, at least) recognize.
3. Programmers should try to use consistent indentation, brace alignment and other formatting things when writing new code, and should try to match the existing formatting when modifying code. Emacs and other modern editors can do automatic indentation and pretty-printing for you, make use of those features and make it easy for programmers to set their editors up to match commonly-used styles. And make them clean up garbage, things like trailing whitespace and irregular alignment are disproportionate pains. I don't care much what the tab interval is, but I hate it when the interval changes every few lines.
4. Use whitespace for readability. Code like if(strlen(obj.getname())" is legal, but it's a lot harder to read than "if ( strlen( obj.getname() ) ". It also makes it easier to distinguish functions ("f(x)") from control structures ("if ( x )"). Similarly, putting the opening brace of a loop or conditional on the end of the line may be compact, but it makes it hard to distinguish the start of a multi-line body from a single-line body followed by some lines with the wrong indentation.
5. A few small formatting things are overall useful. Symbolic constants should be immediately recognizable as such and all-caps is a commonly-recognized way of doing that, for example. And the indentation level of the code should match the logical level, that is the "then" and "else" bodies of an if statement should be indented further than the "if" and "else" keywords (which should both be indented at the same level).

Re:Comments

[weicco]

Oh yes, comments. Well we use comments as version/history information. We have every code file and project file on a single samba-shared volume. When somebody wants to change something he/she shouts "I'M OPENING THE FILE X, DON'T TOUCH IT NOW" and he/she has done modifications he/she adds very informative comment somewhere in the file (name/date/what was done), saves file back to disk and yells "OK, FILE X IS FREE NOW"

Documents... There is no documents. Who needs those anyways? It's much more fun to code something when you really don't have any idea what its supposed to do.

Test plans? Nah, waste of time I say!

Testing? Well, somebody runs it and if it doesn't crash, it works.

I must say I'm in the best damn work place ever! And now if you please, I'll go and find some ethernet cabel to strangle myself.

Re:#defun is sooo 70s...

[goonerw]

And Hungarian notation is soo 90's ;-)

Re:Comments lie

[Lehk228]

disassembly can lie if the operating environment or hardware is bugged (either error or with malicious code)

the only truely trustworthy code is code hand compiled to run on a tube CPU which you have personally blown the glass and formed every tube.

Re:Comments

[Ors]

The primary purpose of the DATA statement is to give names to constants; instead of referring to pi as 3.141592653589793 at every appearance, the variable PI can be given that value with a DATA statement and used instead of the longer form of the constant. This also simplifies modifying the program, should the value of pi change.

-- FORTRAN manual for Xerox Computers

Re:Code cleanly and remove comment

[Anonymous Coward]

Or you could turn it into a Web Service.

Re:#defun is sooo 70s...

[Fembot]

LOAD_DATA + SAVE_DATA == DESTROY_DATA??

(Yes, that's compiler implementation specific, I know...)

Alan

Re:Comments lie

[2short]

My favorite was the entire huge module with only one comment: /* Make sure j != 2 !!!*/

No sign of a variable named j anywhere...