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?"

Comments

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: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

[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

[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)))

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 ;-)