Slashdot: News for Nerds


Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

What Workplace Coding Practices Do You Use?

Cliff posted more than 8 years ago | from the software-development-is-more-than-just-writing-code dept.

Programming 682

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

cancel ×


gnaa (-1, Flamebait)

cococpdalbert (915996) | more than 8 years ago | (#14048777)

GNAA Announces Corporate Downsizing and Administrative Reformation
GNAA Announces Corporate Downsizing and Administrative Reformation

Misha Borovsky (GNAP) - Hollywood - GNAA President timecop announced at a press conference this morning that the Gay Nigger Association of America is in the midst of a large effort to reduce operating costs and streamline business processes. "Layoffs of approximately fifty percent of the gay workforce are to be expected, as well as a shifting in administrative functions," timecop was quoted as saying. Analysts predict this corporate downsizing was made necessary due to over-investment into the New Orleans area, when it was announced last year that the GNAA would be opening a state-of-the-art branch office on the coast. The building was nearing completion and just opening for business when it was destroyed by hurricane Katrina, which has been recently found to be the responsibility of Jews. As George W. Bush is noted for not caring about black people, FEMA has refused to pay for the repairs, and the project was scrapped.

"We are also making internal changes to the corporate information technology intranet," said supers, CTO for GNAA Worldwide Operations. "Many of our information moving processes were running on the Lunix platform, and this was generating large costs due to system slowness and instability. After a careful usability study, we have found that we will be saving millions of dollars [USD] per year by switching to the Microsoft Windows 2003 Server System".

timecop ended the conference by announcing, "We'll always be there for the gay niggers of the world. With this restructuring of the organization, we are enabled to offer twice the service for a fraction of the cost. It's a new gay universe ahead."

About GNAA:
GNAA (GAY NIGGER ASSOCIATION OF AMERICA) is the first organization which gathers GAY NIGGERS from all over America and abroad for one common goal - being GAY NIGGERS.

Are you GAY [] ?
Are you a NIGGER [] ?
Are you a GAY NIGGER [] ?

If you answered "Yes" to all of the above questions, then GNAA (GAY NIGGER ASSOCIATION OF AMERICA) might be exactly what you've been looking for!
Join GNAA (GAY NIGGER ASSOCIATION OF AMERICA) today, and enjoy all the benefits of being a full-time GNAA member.
GNAA (GAY NIGGER ASSOCIATION OF AMERICA) is the fastest-growing GAY NIGGER community with THOUSANDS of members all over United States of America and the World! You, too, can be a part of GNAA if you join today!

Why not? It's quick and easy - only 3 simple steps!
  • First, you have to obtain a copy of GAYNIGGERS FROM OUTER SPACE THE MOVIE [] and watch it. You can download the movie [] (~130mb) using BitTorrent.
  • Second, you need to succeed in posting a GNAA First Post [] on [] , a popular "news for trolls" website.
  • Third, you need to join the official GNAA irc channel #GNAA on, and apply for membership.
Talk to one of the ops or any of the other members in the channel to sign up today! Upon submitting your application, you will be required to submit links to your successful First Post, and you will be tested on your knowledge of GAYNIGGERS FROM OUTER SPACE.

If you are having trouble locating #GNAA, the official GAY NIGGER ASSOCIATION OF AMERICA irc channel, you might be on a wrong irc network. The correct network is NiggerNET, and you can connect to as our official server. Follow this link [irc] if you are using an irc client such as mIRC.

If you have mod points and would like to support GNAA, please moderate this post up.

| ______________________________________._a,____ | Press contact:
| _______a_._______a_______aj#0s_____aWY!400.___ | Gary Niger
| __ad#7!!*P____a.d#0a____#!-_#0i___.#!__W#0#___ | [mailto]
| _j#'_.00#,___4#dP_"#,__j#,__0#Wi___*00P!_"#L,_ | GNAA Corporate Headquarters
| _"#ga#9!01___"#01__40,_"4Lj#!_4#g_________"01_ | 143 Rolloffle Avenue
| ________"#,___*@`__-N#____`___-!^_____________ | Tarzana, California 91356
| _________#1__________?________________________ |
| _________j1___________________________________ | All other inquiries:
| ____a,___jk_GAY_NIGGER_ASSOCIATION_OF_AMERICA_ | Enid Al-Punjabi
| ____!4yaa#l___________________________________ | [mailto]
| ______-"!^____________________________________ | GNAA World Headquarters
` _______________________________________________' 160-0023 Japan Tokyo-to Shinjuku-ku Nishi-Shinjuku 3-20-2

Copyright (c) 2003-2005 Gay Nigger Association of America []

Re:gnaa (-1, Flamebait)

Anonymous Coward | more than 8 years ago | (#14048801)

props to the GNAA for another FP.

Re:gnaa (-1)

Anonymous Coward | more than 8 years ago | (#14048802)

First post! oh wait...

Comments (5, Insightful)

Gyga (873992) | more than 8 years ago | (#14048789)

Tell them to use comments in code, and be sure that they make them good comments.

Re:Comments (5, Informative)

mopslik (688435) | more than 8 years ago | (#14048807) sure that they make them good comments.

And make sure they update comments if changes necessitate it. There's nothing worse than reading through a function's description, complete with well-documented inputs/outputs/conditions/etc. and finding out that those things no longer apply because somebody changed a 1 to a 2.

Re:Comments (3, Insightful)

Threni (635302) | more than 8 years ago | (#14048867)

> somebody changed a 1 to a 2

You shouldn't be using magic numbers anyway - use a #define so that the comments and code stay the same regardless of what the value happens to be.

Instead of



#define LOAD_DATA 1


Then you don't need to care what LOAD_DATA is.

Re:Comments (5, Insightful)

republican gourd (879711) | more than 8 years ago | (#14048974)

Has anybody written an IDE plugin yet to sign comments? You could for instance have a hash that uniquely identifies comment lines 10-20 and code lines 30-70 as the a 'set' of data that is required to match. Then if the hash of either section changes, flag it as a problem until the hash is regenerated.

Re:Comments (0)

PunkOfLinux (870955) | more than 8 years ago | (#14048824)

Yeah. It's a lot easier to understand the code when there ARE comments. Even a person who knows relatively little about programming can understand what does what if the comments are good. For example: if x==456 then //checks for conditional x and executes code if x is true - this is not a good comment if x==456 then //checks to see if x is equal to 456. If it is, then the code within is executed -this is a good, easy to understand comment.

Re:Comments (5, Insightful)

Py to the Wiz (905662) | more than 8 years ago | (#14048903)

"if x==456 then //checks for conditional x and executes code if x is true - this is not a good comment if x==456 then //checks to see if x is equal to 456."

Actually, IMHO, those are bad comments. Too much commenting, while not as bad as too little commenting, is still a problem. Writing too many comments is not only time consuming for the developer, but it makes it harder to find the important comments in the sea of crap. Also, if the program is modified, all the comments must be changed as well. This can be a tedious and time consuming process for large projects.

Personally, I try to use comments for parts in the code that might be confusing. Even for a novice programmer, code like if(x == 456) is self-explanatory, no comments are needed. But complicated statements involving many different variables from different parts of the file may be confusing, and likewise merit comments. Also, comments with input/output or precondition/postcondition for functions might not be a bad idea either.

Use comments when you need them, but don't write so many comments that they become useless.

Re:Comments (3, Insightful)

Seraphim1982 (813899) | more than 8 years ago | (#14048973)

I would say both of those are bad comments. Neither of them tells me something that a very basic understanding of the language wouldn't tell me.
I would say a good comment (that is, a comment that I would find useful) for that piece of code would tell you why the statement was important, what is it going to accomplish, and if needed why was it writen the way it was. For your code my questions when reading it would be "why 456?" and "what is going to happen in the following block(s) of code?".

Re:Comments (5, Insightful)

jomegat (706411) | more than 8 years ago | (#14048978)

BOTH of those comments are bad. If a person knows relatively little about programming, he shouldn't be in a position to modify your code. If they don't know what an "if" statement does, they have no business mucking around in my code anyhow.

Comments should concentrate on "why" not on "what." A machine can figure out "what," so a programmer should be able to do that too (eventually). No machine has a clue as to "why" though.

Any time I'm reading through my code and I can't remember why I did something, it's a red flag - that needs a comment. If the code doesn't look like it's needed, but it really is, you need to put in a comment explaining why it's there.

"What" comments should be reserved for the top of a function or largish body of code.

Re:Comments (5, Informative)

dorkygeek (898295) | more than 8 years ago | (#14048982)

For example:
if x==456 then //checks for conditional x and executes code if x is true
- this is not a good comment
if x==456 then //checks to see if x is equal to 456. If it is, then the code within is executed
-this is a good, easy to understand comment.

Is this supposed to be a joke??! Both of them are worst comments, because they only formulate in english what the code already says by itself. Everyone can see that this is an if-statement, everyone is able to identify the condition, and everyone knows the semantics of an if-statement.

A good comment is not describing what is done (since everybody can see that from the code itself), a good comment describes why something is done, or what the overall objective of the statement is.

For example:

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

This is ways more useful. Even more useful would be to already use self-describing symbol names in the code itself, like

if (currentPosition == finalPosition) { ...

Re:Comments (1)

PunkOfLinux (870955) | more than 8 years ago | (#14048994)

I was simply using them as EXAMPLES. For christ's sake. They were only used because I couldn't come up with something better. Good god...

Re:Comments (1)

Mr2cents (323101) | more than 8 years ago | (#14048970)

While you're at it, try out some documantation extraction tools, like javadoc, ccdoc, or others.

Re:Comments (4, Insightful)

joe_bruin (266648) | more than 8 years ago | (#14049012)

Our coding standard is a little like this:
Write clean code that can be easily understood by reading it. That is, good variable and function names, try not to make any absurdly complicated statements, and have your comments explain the logic of the operations. As for style, try to stick with the style that the original author started with. And finally, all people who use Hungarian notation are locked in the basement and given menial tasks until they repent their sinful ways.

I hope this helps.

Joel on Software (4, Informative)

Marxist Hacker 42 (638312) | more than 8 years ago | (#14048793)

Has several excellent articles on the subject This [] is about as good of a starting place as any.

Programming Standards (5, Insightful)

clockwise_music (594832) | more than 8 years ago | (#14048944)

In no particular order:

  1. Get a development database, a testing database and production database. Yes, you need all three.

  2. Write a few docs explaining each system. Make these are detailed as you possibly can. (This will save you weeks in the long term)

  3. Use software revision control. CVS, VSS, whatever, use one.

  4. Use a bug tracker. BugZilla, Jira, CityDesk, whatever, use one.

  5. Use whatever coding standards the language reckons you should. If java, use sun's standards. If microsoft, use their standards.

  6. Write automated unit tests. I don't care if you're not an agile or XP developer, write unit tests. Check out Junit, or Nunit, or just write your own.

  7. Setup some code so that you can check out ALL code from the source code repository and compile it by ONE COMMAND. Eg, "make" or "ant" or "maven" or whatever. This will take time but is worth it.

  8. Have a naming standard for database tables. This will make your life SOOOO much easier.

  9. Read and don't do anything that is posted there.

  10. Write specs for your new developers. Please write specs for your new developers. Don't just say to them 'fix this up'.

  11. Make sure code isn't hard-coded to a particular directory. Everyone does this. Fix it. (Might be part of step 7)

  12. Create your own standard config files.

  13. Have code reviewed by peers. Don't be a bastard but be nice when picking on people's code.

  14. As mentioned, comment your code but use the language standard. Java - javadocs, Perl - perldocs, etc. These are cool, but don't get too carried away. Nothing can replace a good spec.

  15. Ignore what most people say on Slashdot. (Except for me, of course).

That'll keep you busy for a couple of months! Doing thiswill make you well on the way to having a pretty high level of coding quality. Most companies don't do all of them. Good luck.

Re:Joel on Software (5, Interesting)

ajdavis (11891) | more than 8 years ago | (#14048945)

Yeah, but Joel's an ass. Have any of his worshippers here on /. actually *used* something written by Fog Creek or whatever? FogBUGZ, a web-based bugtracker, seems to be his one claim to fame, & it's terribly mediocre. I mean, mostly it works, but the search function doesn't, the UI is inconsistent, & while you can define filters (such as, "my open priority-1 bugs"), you can't share them, which makes them nearly useless. Joel writes a good spiel, but when it comes to coding, his company ain't the shit.

Plus, he argues passionately for paying programmers well & giving them exciting projects, but in at least two cases he hired interns to start his company's most interesting apps.

Dude needs to work on his street cred.

Re:Joel on Software (1)

keltor (99721) | more than 8 years ago | (#14048987)

There's another person who the OSS community loves to talk about, but have you ever used Yahoo! Stores? (even before it was totally changed)

Re:Joel on Software (0)

bwags (534113) | more than 8 years ago | (#14048967)

Go ahead a buy his book book JOEL ON SOFTWARE (ISBN: 1-59059-389-8) for everyone on your programming team. While you are at it, buy one for management too. It makes for a great read and is extremely useful. HIGHLY RECOMMEDED!

Re:Joel on Software (1)

hackwrench (573697) | more than 8 years ago | (#14048977)

I'm not sure what he meant by grease being "everywhere". Grease should just be on the parts that need to be greased, and nowhere else. I don't know what he means by "yellowing", but rust? Seems to me that if something's rusty, something's wrong. Reading his clarification on the paint, if the heat is causing the paint to turn yellow, the oven should never have been painted with that paint to begin with.

Help people play to their strengths etc.... (4, Interesting)

FyRE666 (263011) | more than 8 years ago | (#14048794)

If you really are starting from ground zero, I'd suggest setting up a repository such as SVN as a good first step. Couple this with a good template to set up standard locations for documentation directories alongside the code trunk and branches (and any other resources your projects requires (images, sound other media). Make sure everyone uses the repo - even if you have to spend a day leading people through it - you'll save time later. This also ensures your projects are backed up (so long as everyone checks in at the end of the day at least), and screwups - such as deleting the wrong directories and forgetting about it for weeks can be reversed.

Obviously there are other issues such as naming conventions, useful comments etc, which are often neglected in small projects, but become more important as more people work together without wars breaking out!

Find out your teams individual strengths and preferences - there's no point trying to hammer everyone into the same mould - some people will naturally gravitate toward, and excel at certain tasks. It's important for efficiency and general happiness that this is taken into account when allocating resources to a project.

Project Automation (1, Informative)

Anonymous Coward | more than 8 years ago | (#14048795)

If you haven't been doing these things, pick up "Pragmatic Project Automation". It may not specifically address coding standards, but it definately will help you get some standards around processes.

Evolutionary Prototyping (4, Insightful)

PIPBoy3000 (619296) | more than 8 years ago | (#14048796)

In my job as a web developer in a healthcare system, I'm all about evolutionary prototyping and other interative [] methods. There's a handful of big projects where we take a more traditional waterfall approach, but even then it's highly modified.

It's nearly impossible for me to get final specifications from a user until they've actually seen something. Paper is okay in a pinch, but a semi-functioning web application is worth a thousand meetings.

Re:Evolutionary Prototyping (1)

inKubus (199753) | more than 8 years ago | (#14048917)

Yeah, I do that too. Just hack together the most basic answer to the problem without worrying about the details, document heavily, send in the analysts and make corrections, rinse and repeat.

Re:Evolutionary Prototyping (1)

OzRoy (602691) | more than 8 years ago | (#14049010)

I work for a small company making web based apps as well and I pretty much am the development team apart from occasional part timers. I've always worked this way and I'm pretty much self taught so I would probably suck at any real project leadership and the way I work is probably very wrong, but this is how I usually aproach my systems.

1) Fast prototype the system. Get a version out as quick as I can that will meet all the basic requirements.
2) Use the system for a while and get lots of feedback about what is right, what is wrong, how is the interface good or bad.
3) Start version 2 by droping the system completely and starting again from scratch.
4) Using everything I learnt from version 1 get a new version coded properly that only does what the first version does. So version 2 is pretty much the same as version 1 feature wise, just better coded, and better user interface. Then build slowly from there adding the requested features.

It's worked pretty well for me, the only problem is the prototype versions often gets used much longer than they really should be.

My boss doesn't care (3, Funny)

b0lt (729408) | more than 8 years ago | (#14048800)

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


Anonymous Coward | more than 8 years ago | (#14048806)

yes! sdfsf sf sf sf asfas fwooooooooooooooooooo!

Standards (1, Funny)

zutroy (542820) | more than 8 years ago | (#14048809)

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.

Re:Standards (1)

xao gypsie (641755) | more than 8 years ago | (#14048992)

no no no, that only works when you are going for the 'most creative code' contest. otherwise the standard protocol involves electroshock therapy, like on ghostbusters.

Re:Standards (2, Funny)

blank89 (727548) | more than 8 years ago | (#14049003)

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

Unrealistic expectations (3, Insightful)

TheNarrator (200498) | more than 8 years ago | (#14048810)

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.

Unless you are dealing with trivial projects it will take more than a couple of hours to figure out the code. Even the best documented open source and commercial projects take a few days to figure out.

Re:Unrealistic expectations (1)

netruner (588721) | more than 8 years ago | (#14048877)

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.

Unless you are dealing with trivial projects it will take more than a couple of hours to figure out the code. Even the best documented open source and commercial projects take a few days to figure out.

Not if you don't care how much you trash the code. Getting something to "work" can be done relatively quickly. Keeping a maintainable piece of code from getting mucked up takes some effort. I see this all the time where I work. The code we have is large (millions of sloc) and people take the OP's path. It now takes over a year before a new developer can even do quick fixes and making it maintainable usually involves a rewrite of a large section of code - if it's even possible. Another problem that this mentaility creates is recurring bugs (I fixed it a month ago, why is it back?). This is because nobody has any idea what anyone else is doing because the code is so hacked up and the architecture is so broken down that people's band-aid fixes are undoing each other.

GOOD code review; Chief Designer at every inspecti (4, Insightful)

mekkab (133181) | more than 8 years ago | (#14048812)

At every inspection; and of course example code for everyone to mimic the coding style.

And good unit test drivers.

Awesome commentary (both at the top of a package outlining the entire low-level design and at the algorithm level) goes without saying.

Oh yeah, and run spell on your code. I mean, really!

That's Like Scrum... (2, Insightful)

Greyfox (87712) | more than 8 years ago | (#14048959)

Scrum and Code Reviews are all well and good but people who've never done that before don't know what to expect, so they tend to be all over the place with their comments. This leads to code reviews where your code is nitpicked over every little thing and scrum meetings that grow and grow until they take 2 hours out of every day to complete. Neither of these things are beneficial to productivity.

I find that a good standard for code reviews is to assume that the programmer knows what he's doing and I don't try to push my political agenda in them. If you want to have a passionate argument about hungarian notation or putting braces around if statements that only execute a single line of code, the code review is not the place to do so. If you think a data structure he used isn't up to the volume of data you'll be running through the system, THAT's something to bring up in the code review.

You can require comments in your code all you want, but I find that you inevitably get something like this: "a++; /* Add 1 to a */" With no indication anywhere of what A is or why you would be incrementing it there. I would propose power stapling the offending programmers in such cases, until they learn not to do that anymore. I would say remedial English classes, but even I am not THAT sadistic.

Looking for magic? (4, Insightful)

YrWrstNtmr (564987) | more than 8 years ago | (#14048813)

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.

That is a pipedream. Any project of significant size will require some immersion before a new proj member can get his hands around the particular bit he's trying code/solve.

Standards can be good, but they're not magical. Unless you're trying to generate a group of little robots, everyone has a slightly different style.

Re:Looking for magic? (2, Insightful)

waldomaniac (861837) | more than 8 years ago | (#14048999)

Good call. Waste a couple of hours?... How many hours are you going to want to spend on the standardization process? And enforcing it? Beware the tools of micro-management... standardization, time-keeping, the dark side are these... Personally, I'm down with the tagline I saw one time:
Comments should be banned - it was hard to write, it should be hard to understand.

We use (0)

Anonymous Coward | more than 8 years ago | (#14048815)

Drunken Style®.

A Good Coffee Break (2, Interesting)

JoeShmoe950 (605274) | more than 8 years ago | (#14048817)

This doesn't directly answer the question, but a nice big break in the middle of the day helps me get myself on track easily. After a few hours of coding, I may start to slow down. If I just take an hour (eat lunch, walk around a little), my brain clears, and I come back fully productive. My work place allows this, and I'm not sure how many others do.

Re:A Good Coffee Break (1)

dorkygeek (898295) | more than 8 years ago | (#14048846)

That's what's called midnight snack, no?

Re:A Good Coffee Break (2, Insightful)

Eberlin (570874) | more than 8 years ago | (#14048930)

A good break in general will clear the mind often enough to get unstuck on some problem. Coffee is optional. I often find that walking around (even just in the room) with a stress-ball, and talking aloud to myself will reveal solutions that wouldn't have otherwise shown up if I were buried too deep in the code.

That and something to scribble on. Either lots of paper or a whiteboard. Whiteboards are cool for getting your thoughts organized. Unfortunately you can't make printouts afterwards...but a good digital camera snapshot of a whiteboard will give you enough to remind you of what you thought up.

The general hint -- give yourself some time to step back from the problem. There are times when it's good to bury yourself in the code and times when it's better to think things through away from the code.

Doesn't matter (1, Interesting)

Anonymous Coward | more than 8 years ago | (#14048820)

Every place I've ever worked has had coding standards, and at none of them were they ever followed. There was never any difficulty telling who wrote what by how they styled their code. Efforts to enforce coding styles by management never succeeded.

Standardize on a good language. (2, Funny)

Anonymous Coward | more than 8 years ago | (#14048821)

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.

Couple of hours (1)

Mr. Underbridge (666784) | more than 8 years ago | (#14048822)

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.

Must be a simple project if you can switch projects and figure things out in a couple of hours. Lucky if it isn't a couple of days.

One Solution (1, Funny)

Anonymous Coward | more than 8 years ago | (#14048825)

Outsource them all.

Let your staff decide (0)

Anonymous Coward | more than 8 years ago | (#14048832)

Assuming you have in house developers, rather than outsourcing everything, You should let your staff (or a committee of them) set the priorities for the development of standards, what standards to use, and review the stndards regularly (annually or so).

They know how they want to work, and also know what bugs them most, so they should set the standards and priorities (with you to guide them).

implementing standards is the easy part (1)

the_mighty_cornhole (926172) | more than 8 years ago | (#14048835)

implementing standards is the easy part...having people follow them is the hard part hopefully you don't work with a bunch of close-minded morons...if you do its gonna be hard to have everyone follow them...if people see and buy into the value that standards offer... it will be a hell of a lot easier.


Martin Blank (154261) | more than 8 years ago | (#14048837)

Get Out Of My Office And Let Me Work In Peace


Get Out Of My Cubicle And Let Me Work In Peace

This applies mostly to the people that come in and have to inform me of their new cat, girlfriend, boyfriend, computer, game, TV, kitchen, car, shoes, and/or midlife crisis (and that's just the top of the list).

A request on the part of the devs under your control: Don't implement a new paradigm every time one comes out. From extreme programming to agile programming, from scrums to design workshops, find something that works in your particular case and stick to it. Your employees will thank you for it (at least in the long run by not planning your demise in the parking lot after the fifth methodology change that quarter).

loose standards are best (1, Insightful)

Anonymous Coward | more than 8 years ago | (#14048840)

If you dont allow people to code the way they naturally can, don't expect any amazing code or new ideas. Their code may also have bugs. Don't buy all the standardizaion hype.

So if you are going to have standards make sure they are loose, and pertain mostly to external interfaces etc. requiring comments or code descriptions or something. I am telling you the worst thing for a project is frustrated programmers because they will make shortcuts in the code. Trust your developers ..u shouldnt be hiring 'em if you arent going to be trusting 'em.

What a question! (1)

cmburns69 (169686) | more than 8 years ago | (#14048842)

At our workplace, we have very few (if any) standard practices.

1) We don't all develop in the same place (some use their HD, and some use a shared drive, some develop over FTP).

2) We don't use the same editors (Textpad, UltraEdit, Homesite, etc).

3) We don't use the same tab settings (Some use tabs, others use spaces).

4) We don't use the same methodologies (Using PHP as an example: Some prefer $_GET while others prefer to enable globals).

Part of the problem is because we came from different backgrounds (Some delhi people, some PHP, some home-taught, etc), but the biggest reason is that we usually don't work on each others code. A couple years ago, we decided as a department to start using some specific coding standards. These didn't last very long, because the company culture has always been one of one-on-one projects, and team-based development simply does not happen.

If you want to implement coding standards in a place where there have been none before, be prepared for blowback from the "grunts". They have been doing it their way, and they are used to it. They probably don't see any reason to change.

The only way for this to be successful is if you either have the power to enforce, or if you can have them catch the vision. At our place of work, I was the only one with a vision.

Good luck to you!

Re:What a question! (1)

masklinn (823351) | more than 8 years ago | (#14048948)

others prefer to enable globals

How come they haven't been terminated yet?

Re:What a question! (2, Insightful)

geekoid (135745) | more than 8 years ago | (#14049006)

I would write people up, and see that it was reflected in there perfomance review.

You work for me, you do it my way. If you think your way is better, present it to me and tell me why. "Cause it's the way I do it " doesn't count.
I'll train you, I'l give you time to set up your editor so it automates whatever you need automating. I'll mentor you, have other developers mentor you. But there is a line where I expect the developer to be up to speed.

Works for some companies not others. (2, Interesting)

jellomizer (103300) | more than 8 years ago | (#14048843)

First language try to choose languages that work well on multiple platforms with at most a recompile. Languages like PHP, Python, Ruby, are Good. If you have to use .NET try to make your programs compatible with Mono. Even if you are using a Windows network and don't plan to switch anytime soon working with platform independent language give you the ability to better negotiate with MS for licensing price because your 3rd party apps will cheaply move over to the new platform. Also programs designed to be platform independent tend to migrate a lot easier to new versions of the OS. Avoid using and single platform library or other 3rd partly libraries unless you really need them. If they stop development you could be stuck.

Second have a Good Data Warehouse try to use Rational Database servers that support Stored Procedures and Triggers, which is dependable. MySQL 5, PostGreSQL, MSSQL, Oracle are all good choices. I would put money to give all the DataBase Servers some good specs and conversly I would put all the data manipulation into Stored Procedures and Stored Functions. Also when creating them give them a prefix to show that they are your companies specialized functions and not built in the Database Server. The Database should give you the data they way that is most convenient for you to use. The reasoning for this is that it normally reduce network traffic to the SQL Server, and allow porting applications to different languages and platforms easier because the data format part is still complete.

Third use have all your apps on your intranet be web based. first it eases deployment and also allows desktops to be upgraded without killing the app every security patch.

So if you make a all your Apps Web Based with the bulk of the calculations on the Database server and having the Web Language handle the User Interface, and depending on you size of you apps a 3 or 4th tear with custom libraries for standardized uses of Interface and data a.

Indentation (1)

Aundy (930631) | more than 8 years ago | (#14048847)

Well of course commenting, good function/variable names are essential, but also i find that it helps alot to keep the way you indent the same. For example before I learned python i used C++ and since indentation was not necessary mine was horrible. Then after learning python I came back to some code that I had made before in C++, and since in python you need to have proper indentation I found it very hard to find my way around the code. I had to go through the whole thing and change the indentation before I could figure out what the code was doing.

Our style! (2, Informative)

Doug Tanner (45196) | more than 8 years ago | (#14048849)

I work for one of Activision's subsidiaries and this is what we use:

int* gpiGlobalInt;

int FunClass::GetSize(int _iArg1, bool _bArg2)
    bool bBool;
    float* pfFloat;
    static int siStaticInt;


Seems to work out well enough.

Re:Our style! (0)

Anonymous Coward | more than 8 years ago | (#14048869)

...thankful I don't work for ActiVision....

Re:Our style! (0)

Anonymous Coward | more than 8 years ago | (#14048894)

Identifiers with leading underscores may be reserved, so you should never use them. See H. Sutter's "Exceptional C++", item 20.

Re:Our style! (1)

Doug Tanner (45196) | more than 8 years ago | (#14048905)

Can you give some examples?

Re:Our style! (0)

Anonymous Coward | more than 8 years ago | (#14048937)

You put the openning braces on the wrong lines.

Re:Our style! (1)

geekoid (135745) | more than 8 years ago | (#14048954)

Man, that is horrible. You should be modded +1 funny.

We promote/hire the most incompetent (0)

Anonymous Coward | more than 8 years ago | (#14048850)

They do have expensive fancy pieces of paper prooving they can memorize things only.

Besides, cleaning up from their constant bumbling affords me the ability to ignore coding practices. There are bigger piles of shit to clean up!

WHAT Standards? (3, Funny)

thepropain (851312) | more than 8 years ago | (#14048854)

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.

Re:WHAT Standards? (0)

Anonymous Coward | more than 8 years ago | (#14048966)

My coding standards involve a standardized shot of vodka on the hour, every hour. That's how I get my versions on.

None... (1)

xquark (649804) | more than 8 years ago | (#14048860)

As simple as that he he he he he :)

Coding Practices (5, Insightful)

Billosaur (927319) | more than 8 years ago | (#14048863)

Here a just a few things that come to mind:
  1. Version Control - find a VC system everyone can agree and use it religiously, whether for scripts, programs, or even web docs. I've use CVS mainly, with a little Perforce, and Subversion is good so I hear.
  2. Coding Standards - depending on how many and what type of languages you have, you'll want to develop standards for how code will be laid out and documented that will make sense and also make it easy for somebody to move from one code base to another with as little trouble as possible. You can be as detailed as like, right down to conventions for naming subroutines and indentation, but don't get carried away or you'll stifle creativity.
  3. Documentation - not just documenting code (which any programmer should be doing reflexively), but documenting system flows and procedures. It doesn't hurt to throw together text docs on your more important scripts/programs, outlining where they live, how they're run, etc.
  4. The Brain Book - there's nothing I hate more than starting a new job and having to learn all those server names, IP addresses, what I'm supposed to have access to, where in the directory tree the stuff I works on live, what types of DBs we use and their versions, etc. So I developed the Brain Book, where I would write these things down as I learned them, to have a point of reference. It's a good idea to do this for all your major projects, so as new people come on, they can spend less time learning their way around and more time coding.
  5. Code Review - everybody's coding style is different and sometimes they don't mesh well or there are divergent opinions on how a particular task should be coded out. Get your programmers together in a room and hash things out as a group. It will provide everyone with a say and may open up some people's eyes to new ways of doing things.

Specs, reviews & tools are the real key (2, Insightful)

VisualVoice (592060) | more than 8 years ago | (#14048872)

From my experience managing many multi-million line code projects for many years, its the tools (source control, bug system, langauges) and a standard documentation templates (market requirements doc, product requirements doc and detailed design document, unit test document) that are more important to standardize than coding guidlines. Sure everyone should follow a good variable naming convention (hungarian or equivalent) and heavily comment each function's purpose, but beyond that you can waste a lot of team time on arguing about idententation, and micro-commenting guidelines.

Also key is a standard process of developer peer reviews. All developers should have peers review specs. New or mediocre developers should have their code peer reviewed. Proven developers can be excused the code review but not the spec review.

Project Management (2, Informative)

LoaTao (826152) | more than 8 years ago | (#14048873)

You seem to be asking more about the basics of Project Management than specific tools. For a fair overview of the subject try this in Wikipedia [] . The grand-daddy of Project Management for software development is SEI-CMM [] .

Project Management first, then everything else (1)

Pasajero (164368) | more than 8 years ago | (#14048875)

Use top to bottom approach:

First of all, have some formal project management training, at lest to get the basics. With this, you will be able to come up with a simple methodology for project requests/paycback/negotiation/scope/development/te sting/release. Then work your way down putting measurable controls where needed on each step of the process.

I have done what you are doing now, and these where the first steps I took when facing a lot of teams with a lot of possibilities on "this is how we run a project" ways to do things.

Experience counts (3, Insightful)

canuck57 (662392) | more than 8 years ago | (#14048886)

My suggestion is get someone who has done this in a structured and successful environment. Otherwise developers will roll you over and your projects will be late, over budget and buggy.

I have seen it so many times where an internal inexperienced person jumps in the saddle without mentorship and guidance in the areas of software development (NT or UNIX) and systems management not native to the environment. And I have seen how long companies suffer with the problems created by this and how much it costs companies in the end. It makes a $1000 per hour consultant look cheap.

A good example is code management. Very few IT shops have it. Why? No one wants to know who checked in the buggy code! But few developers want such tools, especially the microwave generation. But at least when your caffeine isn't good enough and they move on you will know where the source code is.

Sounds simple? Not really, there are hundreds of issues like the one above. And it can't be taught quickly.

So get a consultant for 6 to 12 months that has done this, listen and learn and you will be off to a fast start.

We use this (1)

Sexy Commando (612371) | more than 8 years ago | (#14048889)

We use agile [] programming methods.

code complete has some good things to say (5, Informative)

blackcoot (124938) | more than 8 years ago | (#14048890)

on this particular subject. i believe code complete 2 came out "reasonably recently". that said, were this my task, i'd say the following:

1) document things thoroughly using a tool like doxygen. there is no excuse for interfaces not to be thoroughly documented
2) adopt a standard naming convention. in java, this is easy -- just use the default. in other languages, you'll probably have to make your own up.
3) pick an indentation style. it really doesn't matter which since tools like indent can convert between them almost painlessly. all code that goes into the repository is run through indent to put it into a standard format
4) require that code compile cleanly with no warnings at the most anal retentive compiler settings before it can be checked in unless there are good reasons to ignore the compiler warnings
5) average devs are only able to commit to the "head" fork (or equivalent in your sccs). the code is not committed to the "real" fork until it passes whatever tests you have
6) incorporate tools like valgrind into your testing cycle --- they should come back largely clean. if they don't, things need to be fixed unless there's a really good reason not to.
7) people who check in code which breaks cvs or, upon a code review, are found to not sufficiently adhere to your guidelines owe their dev group donuts.

Re:code complete has some good things to say (2, Insightful)

masklinn (823351) | more than 8 years ago | (#14048986)

3) pick an indentation style. it really doesn't matter which since tools like indent can convert between them almost painlessly. all code that goes into the repository is run through indent to put it into a standard format 4) require that code compile cleanly with no warnings at the most anal retentive compiler settings before it can be checked in unless there are good reasons to ignore the compiler warnings 5) average devs are only able to commit to the "head" fork (or equivalent in your sccs). the code is not committed to the "real" fork until it passes whatever tests you have

5 is not that required since most modern version control tools are able to run scripts on your data before/after the commits.

In that case, the indentation cleaning, compile test and full unit-testing of the modified application could be done automagically at commit, with commit refused if code doesn't seamlessly compile or if any unit test fails (any code change would also, naturally, require the concurrent commit of the modified unit tests for the code).

Pottery Barn rule (2, Insightful)

lanced (795958) | more than 8 years ago | (#14048893)

The pottery barn rule comes to mind: you break it, it is yours. Or at least that's the way it is when I am tweaking the legacy code.

My boss on the other hand, it's more like the bull in china shop. Heck if I know how he got in there, but I know there is going to be heck to pay in the morning.

Documentation and Planning (1)

inKubus (199753) | more than 8 years ago | (#14048895)

These are pretty obvious, but documentation and planning are something you need to stress.

Documentation is the most important, from business rules and operating procedures (this code gets backed up at this time every night) to the code itself. As a project manager, your job is to build a little box for the developers to work in. You want to make sure that all the important stuff is just a simple list of stuff to follow so they can concentrate on coding. Programmers are generally not good at scheduling or remembering to do mundane daily tasks. Get that stuff straight and you'll solve 50% of your day to day problems.

Planning is important. Make sure that there's a good plan that everyone's following. Plan naming conventions and folder/file systems for your code. Then, everyone knows where to look if they need to find something. Simple organization is important. As far as actual development, you need to have a broad plan for the goal of the project, what general steps need to be taken (initial planning, module coding, testing, beta, release, maintain) and do them in that order. You don't need to get crazy with project planning software either; what you want is results, not to dictate how the results occur.

To that line, this box you're building has to be open enough that your developers aren't too constrained to innovate. This means you have to make it kindof a fun challenge to document the code, plan the project, etc. Don't make it seem like it's some chore to document. Force them to pass their code around for a few weeks to work out the bugs; don't wait until you have to. Or start with some dumb easy project that is a small part of the larger problem, and make everyone do one little piece of the planning, then pass it to the other people.

Anyway, this stuff is pretty obvious management stuff. I can tell you that in my 6+ years of business experience with coding and coders, the most important thing is having naming conventions for your files and folders. It seems obvious but when you get a new developer in, he's not going to understand Module3.CreditWidget.x3.1211.c when it could just say "NumberVerifier.CreditCard.c".

The military logistics people have good ideas for that sort of stuff:

-A data element name consists of a prime word, a class word, and modifiers.
-A prime word is the noun designation given to an entity identified in a data model. For example,
a company may need to maintain information about customers, so an entity "Customer" could exist. The prime word for this entity would be called "Customer." The prime word identifies the object to which the data element refers.
-Prime Word Modifier. Prime word modifiers are adjectives that further refine and categorize the
prime word. They designate the name of a data subentity in the data model and distinguish it from other subentities of the same data entity. They are needed to distinguish that data subcategory from other subcategories of data represented by the data entity. For example, a company may be interested in information about two distinct groups of customers, "Retail Customers" and "Wholesale Customers." The prime word modifiers "Retail" and "Wholesale" are used to distinguish between these two types of customers
- class word is a noun that prescribes a definition for a general category of data. A class
word designates the category of data into which a data element fits. Examples of class words are: "Code," "Name," and "Quantity."


Check out Department of Defense Data Element Standardization Procedures []

Good luck.

Mushroom Management (1)

ad0gg (594412) | more than 8 years ago | (#14048896)

At my former job we used this mushroom management [] with great success. While people quit or get laid off we ended up with Lava Flow [] . And it ended up with my favorite practice called "down by the river eating government cheese".

You're fighting an uphill battle (0)

Anonymous Coward | more than 8 years ago | (#14048902)

I've been working for a State government agency now for 3.5 years. No development standards to speak of. We have no formal procedure for launching a project, conducting/managing a project, or deploying and reporting on the project. Developers waste a lot of time reinventing the wheel and learning other people's code bases for maintenance projects. There are still many people who even refuse to see the value of a source code and documentation repository.

My thought is that you have just accepted a practically impossible task. If you don't have unwavering support from management, you'll fail. If you can't somehow get people who've been doing their job for 35+ years without standards to WANT to do it WITH standards, you'll fail.

Expect endless argument about what standards there should be and how far they should go. Expect that no one will be satisfied with your testimony about a proposed standard having worked well for you in the past -- everyone else will deny that your "standards" are solutions to the problems of project maintainability. Expect complaints that "we've never had to do this before" even if you know it's a good idea. Finally, expect it will take a LOT longer than you want it to.

If there's one piece of advice I can give you, it is: start with the very basics, work to expand them slowly, and pick your battles carefully.

Good luck, you're going to need it.

there are three (1)

geekoid (135745) | more than 8 years ago | (#14048907)

          concise comments.

          Use readable and properly discriptive names. Avoid using hard to read code because it makes it faster. Processor are fast,and compilers re pretty damn good. The only exception is code write on top of the machine, But then you should commented well.
Apply the details to all developers. Meaning if you decide to to use 3 spaces for every indentation, be sure all the developers use it. If you use a common IDE, then it should be trivial to make the look consistant.

I'm a big fan of code reviews. It spreads the knowledge around, makes the developer interact, helps ensure consistency, and is a good way to be sure the project is on target. Too many times I've seen wrtitting a tool to help with a project, become the project.

The reason why I becames a fan of code reviews is a long and tedious here goes:

I was leading a team of 4 developers. about 8 weeks before the project was do, I decided to do code reviews. 4 weeks later It was this developers turn. He doesn't show up to work, or the next day, or the next day. I had HR call him, but never got a returned call. At this point I get on his computer and start searching. The only code I found was learning code. Clearly this 'experienced developer' had no experience at all. The team came together and we managed to get his work done, and the project released on time. Saved the bank 100 million dollars. They gave us a football.
I ran into him years later, it seems a dot com where he was the lead developer had gone belly up when they couldn't deliver.

Example programs... (1)

hackwrench (573697) | more than 8 years ago | (#14048918)

When I started out programming I went to the example programs, and ever since then when I want to learn something new I find example programs. Have your programmers write example programs that demonstrate what they expect their code to do. This can also prove useful for unit testing.

infinite number of monkeys (1)

MMHere (145618) | more than 8 years ago | (#14048924)

I've hired an infinite number of monkeys, and seated them at an infinite number of PCs running Eclipse (with File->Quit disabled).

I expect them to have finished writing my code for me by Monday.

Standards (3, Funny)

shoemakc (448730) | more than 8 years ago | (#14048929)

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


UP (1)

chadseld (761331) | more than 8 years ago | (#14048931)

I'm a huge fan of the Unified Process. Note that UP focuses on the software development process, and not the project management process. Also: Set up a Subversion server, use Trac, and put daily announcements on the start page wiki (or similar). Unit Test your code, and make sure to use Javadoc/Headerdoc.

Coding Standards :: E_Not_Enough_Info (1)

lloy0076 (624338) | more than 8 years ago | (#14048932)

Well, coding standards can be very complex to very simple not to mention they're language independent. A coding standard for Perl would almost certainly be different to one for C - simple example, Perl doesn't have /* and */ so mentioning them in a Perl coding standard doesn't make a lot of sense.

Here's some advice though:

1. Take a top down approach and a bottom up approach at the same time

      - What are your broad goals and what do you want your standards to do?
      - What standards already exist in the organisation?

2. Remember, you need to win the hearts and minds of your teams to change

      - Sure you can be PHB and say "Thou shalt", but unhappy coders write unhappy code
      - Listen to your team and get their feedback

3. Don't make wholesale changes because "you can"

      - Otherwise you might end up making things worse

Out of all these three points, if you want to effect change, maintain respect and have coders who you can still herd about, point 2 is probably the most fact, if you have the time and support to do it, getting your programming team to formulate the standards FOR YOU will mean they're more likely to actually follow them because they OWN them :)


Test Driven Development (0)

Anonymous Coward | more than 8 years ago | (#14048936)

Test Driven Development. It's the easiest way to end up with good code and tests that support you when you make changes. And, we all know that we will make changes :-)

Documentation, convention, version control (1)

Roach (15003) | more than 8 years ago | (#14048939)

Contract developers and new programmers joining an organization, especially a small organization, appreciate thorough documentation of processes and modules from an overview down to details on each specific component. Legacy engineers tend to hate documenting so it may require some effort.

OOP helps resolve issues of efficient use of code so that development efforts aren't wasted on modules that may already exist created by previous developers no longer with an organization. A clear naming schema and again, documentation on each class and how it works is very helpful.

Structured programming practices. Documented code. Standards such as variable naming conventions and efforts to maintain code uniformity.

I personally like Version Control with Subversion, we use it in our China office and everything there takes very well to it.

We have learned a lot from our China operation for the organization I am with. They make extensive use of Wiki's [] too. This lends itself well to the documentation task.

I believe the rest is management style and your corporate culture.

Write code that works (1)

georgewad (154339) | more than 8 years ago | (#14048941)

That's what my old boss told us to do.
Also, "If you can't finish it by the deadline, work faster."
fsking brain surgeon.

Doxygen (2, Informative)

segfault7375 (135849) | more than 8 years ago | (#14048946)

One word.. doxygen [] . I had been working on a program by myself for a few years and was really the only one who knew the guts of it. We got a new person on it so I could move on to other things, and rather than spending a week or two showing her what she needed to know, I spent a few days adding doxygen comments to the project, and she was able to read the generated documentation for herself and picked it up in no time. It plugs in to Visual Studio very nicely if you use that, and if not, you can easily write a batch file to update your documentation. I just can't say enough good things about this tool. If you can get your developers in the habit of documenting in the doxygen format, your documentation will basically write itself.


Re:Doxygen (0)

Anonymous Coward | more than 8 years ago | (#14049000)

I second that. Get the programmers to adopt good commenting habits that'll export well using Doxygen and you're golden. Once you get into the habit of placing clean, concise and descriptive 'header' comments before functions, next to members, and so on, the codes becomes insanely readable and Doxygen will produce awesome documentation for it.

Clear automated documentation is absolutely invaluable. But it does mean you have drill into the programmers' heads to adopt a particular style of commenting that Doxygen (or whatever else tool exists) recognizes.

We don't need no coding standards! (2, Informative)

MythoBeast (54294) | more than 8 years ago | (#14048949)

Ok, so the subject is misleading. As a C++ contractor with about 15 years of experience in a broad variety of shops, I've been exposed to quite a lot of different coding standards, from severely strict where they told me where and when I can use the spacebar, to the completely non-existent. Of all of them, I have found the GNU coding standards [] to be the best balance between the flexible and the legible.

A few other details that I'd like to add. K&R braces were invented, not by K&R but by the guys who typeset their book. It is a severe roadbump to try and read code where the braces are at the end of an if statement instead of vertically alligned.

Try spinal alignment for variables. Most people align their variables like this:

int something;
void somethingelse;
longobjectname theThirdThing;

Those with more of a clue align them so that you can find the variable name easily in a mess of them:

int something;
void *somethingelse;
longobjectname theThirdThing;

This puts some major space in some cases between names and short type declarations. Try aligning them like this:;
..........void.*some thingElse;

The problem with this technique is that, if you ever post your code on Slashdot, you'll have to replace spaces with dots and spend fifteen minutes trying to get it to render correctly because SD doesn't support a simple PRE tag.

Other tidbits that have helped. camelNotation rules. Don't use hungarian notation, it doesn't work in a severely object oriented enviornment. Instead, preceed your variables with a single letter that tells you where it's declared. l for local, m for member (of a class or struct), g for global, that kind of thing. I've seen "my" used for member and "the" used for static very effectively, also, but stick to one.

Most of all, good luck. Remember that a lot of people's beliefs in this matter have no foundation except for what they've been doing for years. I have faith in my standards simply because I've seen what happens when you don't follow them, and that's mostly confusion.

High quality management. (1)

Xzzy (111297) | more than 8 years ago | (#14048958)

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

Uh, then might I suggest holding off on pressing the submit button for a few minutes while you go find them? Can just imagine this new project lead in meetings. "Well guys I was going to unveil our new features, but I can't remember what they are off the top of my head."

Little preparation goes a long way.

If I could set the rules.... (1)

Big Smirk (692056) | more than 8 years ago | (#14048965)

1) Every project of significance would have a serious requirements document. By that I don't mean heavy on details, but enough there so that everyone know _why_ we are doing what we are doing. Identify stakeholders, customers etc. Vision statement!

2) Every project will have a preliminary design review. Take the requirements, interpret them, come up with a 'solution' and give a presentation to all the stake holders (or representative stakeholders) and make sure that they understand what they are going to get. Don't just e-mail this around and say "If you have any comments make them now or forever hold your peace"

3) Once the code starts comming together, a critical design review. This is for the technical people. Again, no e-mailing. This is a boring meeting where you pick the brains of experts to make sure you have your bases covered.

4) I'm not big on coding standards. A loose one that governs naming and maybe indentation. I would add perhaps a template for things like header files etc. Maybe the standard copyright notice.

5) Up front, think about unit testing. Having working on a project where the only way you could unit test was to litterally include/link in _all_ the libraries (a hell of a make file) I would think that 'modular' should be in the volcabulary early on.

6) All projects need a follow up plan. Software people need to observe, in the field, how their product works. Hearing about complaints once they've been raised high enough is not effect learning. For me, just recently found out that since one of my dialog boxes was too complicated (it had too much backup information) it was simply being ignored... The title "Database Exception" and the first line "Failed to update database" was being lost (and ignored) in the noise. I would have found out later when the data was all coorupted... fortunately I caught it early. Rather than fixing the code, I instituted a policy of training and beatings for those that didn't comply (in case you were curious).

Peer Review Often (2, Insightful)

ear1grey (697747) | more than 8 years ago | (#14048968)

Establish regular peer reviews: regular, as in daily; and not just when the library is finished and ready for delivery.

Peer reviews encourage developers to describe what they're doing and why they're doing it (not just conceptually, but at the code level) so deeper awareness of whole systems is fostered.

This can lead to projects with less redundancy, and greater integration. It also helps ensure that code will pass any human driven acceptance tests that the commisioning agent may stipulate.

An additional benefit is that utilisation estimates are improved because as developers get better at describing what they're doing, they become better at describing what they plan/need to do.

The canny manager will schedule the peer-review session 30 mins before lunch, recognizing that it gives developers something to discuss as a group whilst eating.

35 years says a lot... (1, Insightful)

clambake (37702) | more than 8 years ago | (#14048969)

I dunno, there aren't too many software companies been around 35 years and still going strong. I'd say go with what's been working. The best "coding standards" are: simplicty, adaptability and readability.

Let programers do what they want. When somone complains that XYZ is hard to read, then it's his job to refactor that code into something that is easy for him to read. Assuming you have the tests you should have written, he'ss have no trouble doing this. If the tests aren't there, then write the tests first so you know if you broke what's already there.

Don't comment your code. Make the code so damn readable that a comment is superfluos.

Above all, don't make rules you can't break on a whim, but do make rules as you find them helpful. Go with what feels right until it stops feeling right and then fix it.

The first person who says something unhelpful as "your code doesn't comform to our company mandated brace alignment standard" gets fired, but only after he's shown what a modern IDE looks like and how well it autoformats the code to any brace standard he cares to think of.

Standards? Practices? (0)

Anonymous Coward | more than 8 years ago | (#14048981)

None. Boss decides at will, changes mind every other day, cow orkers feel numb. Anybody anything to offer, career-wise?

document functions/classes (1)

dindi (78034) | more than 8 years ago | (#14048990)

Force the programmers not just to comment the code, but to write usable docs for classes and functions.

Some programmers do not have to understand what's in, just to call a function ... this is pretty much "everyone knows" but pretty much missing from many places ...

Technically sometimes you spend days just to figure the mess out until you can even start typing a line, while with decent docs, you can start fast....

Also diagrams, flowcharts and the like might help others to see thru a system faster...

I mostly worked as a sysadmin, but even at relatively large installations I sometimes missed a simple network map..... I remember at least 2 places where my work started manually discovering (mean, room by room, flashlight in hand, cable end to cable end between routers, hubs, firewalls) what the hell was happening at the place.....

The funniest (or most sad) was when I found a firewall at a new place, connected into itself. The "admin genius" kept the owners beleive that they are protected by a firewall, while in fact it was just connected to a hub with all 3 interfaces, default config

I have also been to a place, where 3 programmers/designers (web project) worked on a project for half a year (no docs, no nada, no software) and all they did was surfing the net and waiting for it to turn out.

This is a bit extreme, but actually no one noticed, as management had no clue how long it took what they did, until we estimated it 4-5 days of work for a team of 2 max. I don't know if I felt sorry for them at the end, but the whole office got fired alltogether 3 days later.

My point is: make them document what they do, that also tells if they do anything at all (in case you have a non tech manager, or you are not in their field).

I feel your pain (0)

Anonymous Coward | more than 8 years ago | (#14048995)

I'm a year into a job that sounds very similar to what you're describing. I took some advice from friends and instated some of the following procedures:

1) Meet with the relevant stakeholders in the new project. Come up with a detailed list of requirements.

2) Meet with the staff who will be implementing this project, go over the requirements and come up with a rough estimate of the time and resources required to complete EACH requirement. This estimate can be plus or minus 50%. Identify areas that will require additional research or testing in order to refine the resource estimates.

3) Meet with the stakeholders again, go over the time/resource estimates. Deal with any ambiguity in the requirements and get their buy off on the current estimates for time and resources.

4) Meet again with the development staff, spec out the entire project with milestones and completion estimates ( this estimate can be plus or minus 10% ).

5) Codify the requirements and the specs for the project into a single document. Include all time and resource estimates. Have the stakeholders (including any relevant middle or upper managers) each sign this document with the understanding that any deviation from the requirements will immediately void all estimates.

I realize that this seems top-heavy with meetings, but once you've gone through it a few times you'll see why its necessary. Having all the stakeholders agree to the requirements and their estimates will protect your staff from scope-creep and unreasonable deadline changes. You'll also find that the more you plan in advance, the easier the implementation will be and the more robust the end result is likely to be.

Worry about what not to do, too (5, Insightful)

Rocketboy (32971) | more than 8 years ago | (#14049001)

Many (many) moons ago I worked for an IT manager who's explicit instruction was, "don't use arrays." He didn't understand them and, therefore, they were bad.

The moral of the story?

A. You are not the font of wisdom. If very lucky, you are the point of the pen. Rule carefully.

B. Don't make standards based on what you learned in school. Base them on what you learned in real life.

C. If an Old Fart tells you that one of your edicts is stupid, don't assume that they're resistant to change just for the sake of being crotchety. Maybe they learned something useful over all those years and all those lines of code.

Well I don't know.. but (0)

Anonymous Coward | more than 8 years ago | (#14049004)

Use python.

Then you automatically get the code standard. Well, if you are going to be strict of it, you will have to set some *standard* too but, usually many of python codes have very similar way of coding style unlike C or C++ that should have to be explicitly defined. Above mentioned PHP isn't such a good choice since it sucks.

If you are going to use ALL linux or ALL windows, platform independent isn't such a big concern anyway so you don't have to consider mono if you are going to use .NET which is suck anyway.

You can have C extensions with python. When C only to be used, it is pretty much of suck but when it's used with python you get very clean structure of code since you will code it with C when only it's bottlenecked. There's good optimizer/profiler called psyco. And many numerous such extensions.

What makes python so structured is, it's almost *configurable* structure, not being compositable. So you already have a basic structure, only you change the small pieces even it seems like making a graphical theme of a skinable applications.
Since everyone already know about middle picture, people only have to read the big part and super-little part(C extensions). Middle part is defined, and little part is configurable thus it's standard.

Waste a couple of hours? (1)

dlaur (135032) | more than 8 years ago | (#14049013)

Sorry, but it is going to take a lot more than a couple hours for any programmer to jump in and figure out the code for any non-trivial program no matter how conventionally it is coded. The statement (which I am taking too literally) is wishful thinking.

I get the point though, coding standards are critical so that people aren't confused when they look at someone else's code and it is following completely different conventions. It doesn't matter which coding standard you use as long as everyone agrees with it. Try to create consensus on the conventions and allow them to evolve. Forcing things down peoples' throats won't work.

Focus on getting peer reviews into your process as early as possible - like the same day the code is written - maybe even at the same time the code is written. If you wait too long to review code, the author gets a little attached to it and often too defensive. Constructive criticism is more easily accepted before someone has traveled a long road and doesn't want to backtrack.

We have been implementing Project Management (1)

Gonarat (177568) | more than 8 years ago | (#14049014)

We have been dealing with this in our organization. In the past, we have been programming by the seat of our pants -- we get requirements, program what we think our Customers want, do a little testing, then throw it into production, then wonder why we have problems in the middle of the night.

Sarbanes-Oxley plus the competition is putting an end to this method of coding. In the past year, we have hired real Project Managers and have begun doing real Project Management.

We now require a Functional Systems Design (FSD), a document that details what the customer wants at a high level. A Computer Systems Design (CSD) document is then written. This document is the actual design of the system that Developers and Programmers use to design the system, design and build databases, and determine what programs need to be written and computer system(s) (PC, Mainframe, Unix)they will live on. Once the programs are written and unit tested, we have a QA department to do real testing. We currently use Microsoft Project, TrackRecord (a Compuware defect tracking tool), and Bugzilla (an open source tracking tool) to track what has been done, what defects we have run into, and how they were resolved.

We still have a long way to go, and have faced opposition from some Managers, but support from Upper Management (and auditors) has helped to pave the way.

Implementing change is tough, but it is starting to pay off in better designed and implemented software which helps keeps our customers around (which means no layoffs, at least for now). Getting requirements in writing is a big help when it comes to analysis and design -- it by no means eliminates problems, but it sure does help reduce them.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account