Good programming practices versus speed of ad-hoc programming

Question

I know good programming practices always help in the "long run" for a project, but sometimes they just seem to cost a lot of time. For instance, its suggested that I maintain a header file and a cpp file for each class that I make, keep only the declarations in the headers while definitions in cpp. Even with 10-12 classes, this process becomes very cumbersome. Updating the makefile each time a new class is added dependecies and evthing .. takes a lot of time...

While I am busy doing all this, others would just write evthing in a single fie, issue a single compile command and run their programs ... why should I also not do the same? Its fast and it works?

Even trying to come up with short, meaningful names for variables and functions takes a lot of time, otherwise you end up typing 30 character long names, completely unmanagable without auto complete

Edit :

Okay let me put it a little differently : Lets say i am working on a small-medium size project, that is never going to require any maintenance by a different developer (or even me). Its basically a one time development. Are programming practices worth following in such a case. I guess my question is, do the good programming practices actually help during the development, or they just pay off during maintenance ?

Answer 1

The downside of the ad-hoc is in the long-run, when it comes to maintenance (especially when the maintenance coders are people other than yourself). Such techniques might be OK for quickie proof-of-concepts, but will cause more problems in the future if you don't rebuild properly.

Answer 2

I haven't been working in the field for long, but not slacking off and documenting as I go, defining variables with useful names, etc...definitely saves time in the long run. It saves time when the other developers/myself go back to the code for maintenance.

Not stuck wondering what this variable means, why did I do that, etc! :)

Answer 3

Yes, it's worth doing it "right" ie good, because, basically it's pay me now or pay me later, and, you're not the only person who will ever see the code. If it takes you 15 minutes now to do it "good" - how long does it take you 6 months (or more) from now to figure out what was meant - in your own code!

Now, you could use Martin Fowler's 3 strikes idea for refactoring. First time in the code to fix some thing , notice it could be refactored, but you're too busy and let it go. Second time back in the same code, same thing. Third time: refactor the code.

Answer 4

The effectiveness of programming practices doesn't seem to be your problem, here. What you should be concerned about are the tools you're using to develop. There are plenty of IDE's and other options for keeping your make files automatically up-to-date, for example.

Answer 5

Laziness may pay off right now, but it will only pay off once. Taking the time to do it right doesn't pay off immediately, but it will do so multiple times and for a longer period of time.

Also, there is nothing wrong with really long variable and method names, unless you subscribe to the naive view that most of the time you spend programming is used on typing and not solving problems.

Addendum: If it is hard to name succinctly, it probably needs to be broken down into more modular units. Method or variables that are hard to name is a definite code smell.

Answer 6

Its all about long term supportability. Clearly you have either not been coding on a team or not had to look at code you have written years ago. I can open code I have written 15 years ago and modify it with very small relearning curves if I have given meaningful variable names, while if I have not it will take some time to figure out what I was doing with that X and that H, and why T should not be more than 4.

Try sharing code with 10 people on a team and have each of them just put code in any place they like... I have worked with people like that. If lynchings still had public support, I would have lead many. Picture this... I know I need to modify the signature on Foo.SetFoos(int FoosInFooVille), but I looked for Foo.h and it was not found, well now I just look for Foo.cpp right? Oops, to save... time?... they jammed Foo.cpp into Chew.cpp... so I look there... its not at the top of the file! Do I find Foo in that file and see if its above that... sure... nope, not found... its in Chew.h. Now I am ready to check the SVN log and target my USB powered missile launcher at that jerk next time he passes by.