Slashdot Log In
What Workplace Coding Practices Do You Use?
Posted by
Cliff
on Wed Nov 16, 2005 08:02 PM
from the software-development-is-more-than-just-writing-code dept.
from the software-development-is-more-than-just-writing-code dept.
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?"
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Comments (Score:5, Insightful)
Re:Comments (Score:5, Informative)
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.
Parent
Re:Comments (Score:5, Insightful)
Parent
Re:Comments (Score:4, Interesting)
Parent
#defun is sooo 70s... (Score:4, Informative)
enum {LOAD_DATA, SAVE_DATA, DESTROY_DATA}
Paul B.
P.S. And of course my all-caps enum values were considered too lame by lameness filter...
Parent
In addition... (Score:5, Insightful)
More importantly: Don't be too clever.
It's when people try to get clever in their coding that it gets hard to read. And, quite frankly, that's the code that generally breaks most easily.
Parent
Re:Comments lie (Score:5, Informative)
Parent
looong functions (Score:5, Informative)
This is so fucking wrong and wicked the programmer who did it should go straight to hell. I'm sure there's no functional coesion in there: most likely there are many disparate tasks that should be each in its own function and called from there. I'm sure there is a lot of cut-n-paste in there that should be each in its own function and called from there.
I'm sure you can guess where i'm willing to get to... more important than hungarian notation, comments or documentation in PDF format is abiding for these 2 simple rules: KISS -- keep it simple, stupid -- and DRY -- don't repeat yourself. Once you do it, coding and reading code is a lot easier.
So, my advice:
* Give meaningful names to important, global, business rules variables ( local variables like i or c are ok, since they are mostly irrelevant ) or functions/methods/procedures/subroutines
* Write short, highly coesive functions/methods/procedures/subroutines
* Stop the cut-n-paste madness! If you do it a lot, it's obvious the copied code if begging to be parametrized and be given a name. Programmers altering your original code will be thankful
* Write modular code, not a plain, huge, stupid monolithic wall of letters. Even in languages with no namespace support ( C/PHP etc ) a good naming convention for functions of a certain module/header can do wonders...
* and please: meaningful names don't mean phrase-like names like thisLocalVariableIsCool. Conciseness go a long way towards good readability...
Parent
Re:Comments (Score:5, Insightful)
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.
Parent
Re:Comments (Score:4, Interesting)
There is lots more to coding standards than just comments and style. Where I work, portability and maintainence are of high concern too. Certain rules, like no hard-coded values such as 563, allow for much better code maintainence. Other rules, like in C/C++ never using an int for any value other than 0-127, and never using a char for anything other than text characters, allow for code portability. These are just some of the rules. If your product is designed for one environment, you may have different coding standards. In the past, we have gotten together as a software team and reviewed other standards found online and combined the likes and the like-nots to create our own, tailored for our industry and requirements.
Style is good for readability and also for consistency. Requiring spaces before and after operators like = and + help in reading complex lines. Parens () help also. Setting requirements for function bracing (or what goes on a line, depending on the language), and tabbing help multiple programmers understand and easily see the program flow of others.
Anyone who protests that they like their own style better because they can read it eaiser (while everyone else can't) shouldn't be working for you. Team players are needed. We've resolved many such arguments satisfactorily in the past by simply putting it to a vote. And those team players gracefully accepted the majority.
Parent
Re:Comments (Score:5, Insightful)
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
Well that's a good start, with good intentions, but you need to have a standard definition of what constitutes good function names and good variable names. If you have 5 different programmers on a project, you'll have 5 different opinions on what good names are.
Make sure your coding standards are DOCUMENTED.
If it's a java project, the best source would be Sun's java coding standards. A very useful tool for this is Checkstyle. [sourceforge.net] You can decide which rules to enforce (some of the ones enabled by default are more annoying than anything) but if you take the time to get your code to where Checkstyle likes it, you'd be amazed how easy it is for humans to read.
As for my department, we use CVS for version control.
Every time code is checked into CVS, it is formatted by Jalopy. So, it'll look nice and neat the next time it's checked out.
Also, we have a script that does nightly builds, and then emails the result to everybody on the team. So if you checked in something that breaks the build, everybody knows about it the following morning.
We have a regular release schedule. All work is done on the main CVS branch, but when it's time for a code freeze, the new version is branched off and tagged in CVS. During QA testing, bugs are fixed in the branch and the mainline. New features are only added to the mainline.
When we are ready to deploy, we tag the release in CVS. The deployment script checks the tag out of CVS, builds it, and packages everything up into the relevant
This is all a very strict process, but things rarely fall through the cracks this way. If you don't have any processes in place now, it's best to implement them a step at a time. Get everybody used to working with CVS or some other version control, get them used to the notion of tagging and branching, and make sure there's actually a document detailing whatever processes you have.
And lastly, have code reviews every week or two. Review a different person's code each time and make sure everybody on the team is allowed to have input. If you're not at the coding stage yet, have design reviews.
Parent
Re:Comments (Score:4, Insightful)
Also, have a simple set of automated test scripts and require that every change must build and pass all of the scripts before being checked in. Also have a more in-depth set of test scripts that are run on a regular basis, and make sure that failures are fixed. Finally, make sure that you have a test org in charge of maintaining the scripts and adding new ones, so that your code doesn't become 'immune' to your tests.
Parent
Re:Comments (Score:4, Interesting)
So what if they are not all uniformly named? Has anybody actually seen a code base where it's possible to call a random function in a class without looking at documentation or the header file? As long as it's an informative name - and code reviews should flag bad ones - you should save your fight for something that actually matters.
Guidelines on naming, on the other hand, is a great idea. Clubbing smart developers over the head for this is pointless.
if you take the time to get your code to where Checkstyle likes it, you'd be amazed how easy it is for humans to read.
One of the myths of software engineering, IMO, is that code is hard to read. For a competent programmer, code is *not* hard to read, in the sense that it's pretty easy to figure out what the code is doing. The problem is what the code is attempting to do, and possibly why. This is why brace styles, spaces versus tabs, and other "low level" coding standards do very little except to annoy. I've worked at several companies, each with different coding conventions, and I follow most of them. Unfortunately, I've found little relationship between maintainability and adherence to coding standards.
Parent
Re:Comments (Score:4, Insightful)
Parent
Re:Question about Hungarian Notation (Score:5, Insightful)
// the old c style
if(cur == last) rec->tag = name;
// camel case
if(currentKey == lastEntry) Record->keyTag = userName;
// hungarian
if(iCurrentKey == iLastEntry) prRecord->m_pszKeyTag = pszUserName;
Now imagine discussing them with your coworker. Imagine thinking in your head "What should I do if prRecord->m_pszKeyTag is NULL?" Humans are good at symbolic manipulation. Giving something a name makes it easier to deal with. Giving something a label that cannot be easily manipulated in language (spoken or in your head) severely hampers the ability to think it through.
The argument for Hungarian is usually "but it lets you know what the variables are". This is the maintainance programmer argument. This argument rarely makes sense in reality, unless some very bad programming is involved. First of all, if you do not understand the current code you are about to modify, you should *not* be modifying it. If your maintainance programmer is just going to have a look at two lines of code, add a third in the middle, and hope for the best then you are truly fucked. He has obviously not understood the code enough to know what the consequences of the modification will be. The reality is, if your current logic unit is such a monstrosity that looking up the types of your variables is a burden, and your variable names are so poor that it is insufficient to infer at least a basic understanding of what is going on without having to resort to prepending types, you should probably step away from the keyboard, turn off your computer, and tell your boss that you had an epiphany and will be pursuing a career in French fry development.
Parent
Re:Comments (Score:5, Interesting)
The best advice I ever got was to write "why", not "what" a piece of code does.
See? Completely useless. Let's try again:
Ah, much better! Any Computer Science peon knows that "counter++" increments counter. What they might not know is why. Those simple bits of "why" comments can make reading code so much easier.
Organizational comments (those that delineate what chunks of code inside of a method do) can be helpful, too. (Ex: "// Normalize string", "Encode string", "Send String") They make narrowing in on a particular "task" performed in a method even easier.
Other than that, however, the biggest and most persistent and most annoying problem I have is poorly-engineered code. Some people just do not know how to apply their college degrees. I wish CS degrees had a bigger emphasis in software engineering. Would you hire an architect who couldn't design anything bigger than a porta-potty? Why does the CS industry get away with doing the same thing?
Parent
Code cleanly and remove comment (Score:5, Insightful)
messages_processed++;
This actually makes sense without the comment.
Parent
Re:Comments (Score:5, Insightful)
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.
Parent
Re:Comments (Score:4, Insightful)
Parent
Re:Comments (Score:5, Insightful)
People forget that code itself is a language. And usually a much more clear and logical one than English. Requirements docs are for explaining complex business processes and code itself explains most of what is going on. That is not to say that comments are not important, but when they exist I want them to be there for a reason. Anyone reading your code is assumed to be conversive, if not fluent in the code language, so comments should explain things such as:
Comments that merely "translate" basic code language into english are at the very least useless and often harmful: they bloat the filesize, obfuscate executable lines (I have deleted blocks of apparent comments only to find that unit tests are subsequently failing - the reason? - a single line of executable was buried between 2 dozen lines of commented out code), increase the burden on the maintainer and/or reader who must sort out the important details from the quotes laid down by Capt. Obvious.
Parent
Re:Comments (Score:5, Funny)
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
Parent
Re:Comments (Score:5, Insightful)
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.
Parent
Re:Comments (Score:5, Informative)
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:
This is ways more useful. Even more useful would be to already use self-describing symbol names in the code itself, like
Parent
Re:Comments (Score:5, Informative)
Amen to that.
In addition to the original comments being redundant, there's also the issue of the code and the comments getting out of sync...
The company I work for just wrote up a formal coding standard, which includes everything from a guide to our internal hungarian notation, indentation guidelines, and even which C++ features/paradigms are supported, frowned upon, or not allowed. All the coders got a chance to send in feedback before it was finalized, and we even ended up with a list of recommended reading on the subject, including:
The idea is to keep the code readable and maintainable with the least amount of re-invention of the wheel. With good coding practices, it's easier to avoid bugs in your own code and spot them in others (reviews are also a big plus on both counts). And it gets any religious battles out of the way up front, so you don't have to waste time bickering later on.
Parent
Re:Comments (Score:5, Insightful)
If you write the code first, then annotate, you fall into two traps: "What the heck was that variable for?" forgetfulness, and "It works so stop messing with it" laziness.
Parent
Re:Comments (Score:5, Funny)
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:
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:
Really, a little extra work up front goes a long way.
Parent
Re:Comments (Score:5, Funny)
if x==456 then
That way, there's less chance for confusion if the code gets modified in the future.
Parent
Re:Comments (Score:4, Funny)
Parent
Joel on Software (Score:5, Informative)
Programming Standards (Score:5, Insightful)
- Get a development database, a testing database and production database. Yes, you need all three.
- Write a few docs explaining each system. Make these are detailed as you possibly can. (This will save you weeks in the long term)
- Use software revision control. CVS, VSS, whatever, use one.
- Use a bug tracker. BugZilla, Jira, CityDesk, whatever, use one.
- Use whatever coding standards the language reckons you should. If java, use sun's standards. If microsoft, use their standards.
- 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.
- 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.
- Have a naming standard for database tables. This will make your life SOOOO much easier.
- Read thedailywtf.com and don't do anything that is posted there.
- Write specs for your new developers. Please write specs for your new developers. Don't just say to them 'fix this up'.
- Make sure code isn't hard-coded to a particular directory. Everyone does this. Fix it. (Might be part of step 7)
- Create your own standard config files.
- Have code reviewed by peers. Don't be a bastard but be nice when picking on people's code.
- 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.
- 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.Parent
Re:Programming Standards (Score:4, Interesting)
6.a Formalize the testing process by people other than the original developers.
6.b Write test cases.
6.c Do regression testing. Especially for "transperant to the user" changes.
8.a Have a naming standard for table columns. This will make your life SOOOO much easier.
11.a Where you do need hardcoded directories, externalize the locations in configuration files.
Parent
Re:Joel on Software (Score:5, Interesting)
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.
Parent
Help people play to their strengths etc.... (Score:5, Interesting)
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.
Evolutionary Prototyping (Score:5, Insightful)
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 (Score:4, Interesting)
What's amazing is that you can say that in two sentences, and most web developers here will completely get what you mean... and that traditional managers (of developers) will get incredible hives and seriously rethink your annual bonus for uttering such heresy.
My favorite flavor of Not Getting This are the managers or customers that want you to mock up some screen shots for discussion, and are happy to pay for you to do so in Visio, or a paint program, etc... but if you instead actually whip together some HTML-based forms (much of which can eventually go towards further prototyping or actual use), you've opened the door to arguments over charges for having "jumped the gun" on the programming cycle. Never mind that I can produce conceptual mockups that actually render on a browser faster than by most any other means. But since a cheesy little pull-down-generating server-side script is "programming," there's PHB-fodder about having already done dev work before all of the requirements are described. Oh well. I'd rather write off a chunk of the project's proceeds than try to hammer out all of the requirements on paper first. In real life, with projects that must go from "I saw this thing when I checked out at Amazon" to being functionally bolted onto an existing web presence in a matter of a dozen man-hours, that's frequently impossible.
Parent
My boss doesn't care (Score:4, Funny)
Unrealistic expectations (Score:4, Insightful)
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.
GOOD code review; Chief Designer at every inspecti (Score:5, Insightful)
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!
Looking for magic? (Score:5, Insightful)
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.
Coding Practices (Score:5, Insightful)
Experience counts (Score:4, Insightful)
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.
code complete has some good things to say (Score:5, Informative)
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.
Standards (Score:4, Funny)
-Chris
Worry about what not to do, too (Score:5, Insightful)
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.
Geek minds (Score:5, Insightful)
Someone commented that the difference between Microsoft and Google is that Microsoft programmers are holding concepts the size of "If...Then...Else" and Google programmers are holding concepts the size of Bayesian filtering; thus, Google's Geeks are better at making big, coherent plans without getting lost in the details. It's not 100% true across the board, but it's an insight.
As a Project Manager, then, your job is to:
1. Allow your Geeks to transfer the concepts from the screen/page/whiteboard into their heads; and
2. Allow your Geeks to hold those ideas easily once they've got them.
Step 1 is a bandwidth issue: make the "inputs" more efficient by, for example, giving all of them dual-head monitors and high speed printers, so they can get lots of code into a usable format for reading (some of us prefer printouts; others just need vi/Emacs and a flicker-free monitor). Step 2 is a quality issue: Geeks who have to hide in headphones or run away to the park to read because of ringing phones and nagging managers are NOT going to be able to do their job.
And with any data pipe, throughput is more a function of time rather than pressure. So your dream of getting your programmers up to speed in minimum time really is -- pardon the pun -- a pipe dream. They won't be any use to you if they don't have the time to learn the systems they're working on.
Never comment! (Score:5, Funny)
-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
Ahahahahaaa... heh... Snrrrrrkkk. Kidding, right? (Score:5, Informative)
A couple hours???
Look, no offense, but you either only deal in "toy" code, or you have such high expectation that you will fail, and quite spectacularly.
A new coder, even an experienced one, takes days or even weeks after coming into an existing project before he can contribute anything but the most trivial of changes. For a truly massive project, or one that requires intimate domain-specific knowledge in a niche industry, extend that to months.
If you can find a way to get an unfamiliar newcomer up to speed on any "real" project in a matter of hours, consider your talents wasted in your current position.
Fundamental coding truths (Score:5, Insightful)
I recently put together a list of Fundamental Coding Truths after musing about this topic and why it was so hard to plan software development:
1. Software is not at its core a collection of a few clever algorithms.
Rather, it is primarily (in the ways that matter) a huge collection of arbitrary
choices and random implementation details.
The algorithms that consititute the mathematical/logical basis of a piece of software
are an important, but very small (eg: 1%) and relatively very simple part
of the overall code.
2. Code complexity is pretty much exclusively determined by the (combinatorial)
number of interactions between pieces. Each interaction requires at least one decision
and usually many more.
3. Because of #1 and #2, deep, intimate familiarity with the code (this vast
collection of implementation details) is only ever fully knowable to the original
author(s) who made these uncountably many, mostly arbitrary decisions.
(Familiarity by secondary authors/maintainers comes primarily from
re-writting sections of code.)
4. Because of #3, programmers are not interchangeable. The efficiency with
which a person can navigate the code, implement or even imagine changes
is almost entirely determined by how familiar they are with these many, many small
details. The ratio of efficiencies between a primary author and another
equally talented coder is very large (eg: 100). Because of this, the original
authors of a section of code are usually the only ones who are ever able to efficiently
modify or restructure it. This becomes rapidly more true as the the size and
complexity of the code increases.
5. Because of the complexity of code (the number of interactions and interdependencies),
debugging and maintenance constitutes the vast majority (eg: 99.9%) of the work
required by a piece of software over its life.
6. Because of the complexity of code (number of interactions between components), it is
very hard, if not impossible, to predict with any accuracy what will be involved in implementing
a given change. Even for original authors, unintented side effects are almost inevitable, and
the primary determinant of the length and difficulty of a task lies in finding and rectifying
unintented consequences or unforseen interactions. Because of this, the uncertainty in the time
it will take to execute a change is very large.
(eg: 10x range in 95% confidence limit of time estimate, say 1 day-2weeks).
7. Because of the complexity of code, bugs are an inevitable byproduct of writing code. It is hard
to predict how long it will take to find and repair bugs as that depends on how many side effects are
involved, which is not known until the repair is done and "fully tested". The only way to avoid bugs
completely is to not write code. There are things that can minimize bugs or speed up finding/fixing
them, but they will always exist.
For .Net, here is what we use (Score:5, Informative)
VB -
Version Control -
Server: Subversion + Apache
Client: Tortoise SVN (Excellent) [We also use Perforce, CVS, VSS(Commercial apps)]
Continuous Integration - Cruise Control.Net
Intranet, Knowledge Management - DotNetNuke (www.dotnetnuke.com)
Project Management - dotProject (PHP) (www.dotproject.com), MS Project
Unit Testing - NUnit (www.nunit.org)
Coding standards (Score:5, Funny)
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: