[Don Hyde] SNIP > No and lets not turn this into some kind of flame war im 22, still in > school majoring in electronics engineering tech. I have majored in > software engineering but changed my major after 2yrs. > [Don Hyde] SNIP > So now how did this turn to a big argument that i suddenly dont know > anything about programming? > [Don Hyde] SNIP Most older programmers have had the painful experience of having to modify (under a deadline of course) un- or poorly- documented spaghetti code written by someone else or, worse, by themselves. That code was undocumented for all the usual reasons -- too simple, never going to be used again, not enough time, just written for myself, etc., or there was documentation but it was separate from the program and got lost. When someone (especially one who is probably younger) tells them they're wasting their time, they recall the pain, and cry out. Really, they're not stabbing at you, they're trying to save you some of the pain they have experienced. So they learn to always at least take a stab at using comments to explain the confusing parts of a program. You never know when that code will come back to haunt you or someone else. This goes along with a whole set of practices like descriptive labels and variable names that help to reduce the confusion and misunderstanding when a human needs to read the program. It's cheap for a machine to read the code and "as long as it works" it doesn't matter how it's written, but when it stops working, a human has to read it, and it's mongo expensive for a human to read the code. Even if it only helps a little, clear writing will save some pain (which is money when you're programming for a living). I think it might be a good idea for would-be programmers to study writing for humans first, then take on the easier task of writing for machines. Always keep in mind that the poor bastard who's going to have to try and figure what the !@# this code was supposed to be doing two years from now -- has a good chance of being you.