Are You Proud of Your Code?

An anonymous reader writes "I am downright embarrassed by the quality of my code. It is buggy, slow, fragile, and a nightmare to maintain. Do you feel the same way? If so, then what is holding you back from realizing your full potential? More importantly, what if anything are you planning to do about it? I enjoy programming and have from a young age (cut my teeth on BASIC on an Apple IIe). I have worked for companies large and small in a variety of languages and platforms. Sadly the one constant in my career is that I am assigned to projects that drift, seemingly aimlessly, from inception to a point where the client runs out of funding. Have any developers here successfully lobbied their company to stop or cut back on 'cowboy coding' and adopt best practices? Has anyone convinced their superiors that the customer isn't always right and saying no once in awhile is the best course of action?"

Comments

Something to note about other people's opinions

[suso]

One thing to keep in mind when determining the quality of your code is that other people will most likely criticize the quality of your code. Usually saying that it sucks, when usually its just the person having their own way of doing things. I don't know why this is, I think its just human nature.

I've seen time and time again programmers taking over for other programmers' code and saying that the previous person's code sucks. Its like a right of passage or something.

Re:Something to note about other people's opinions

[DeeQ]

One thing to keep in mind when determining the quality of your code is that other people will most likely criticize the quality of your code. Usually saying that it sucks, when usually its just the person having their own way of doing things. I don't know why this is, I think its just human nature. I've seen time and time again programmers taking over for other programmers' code and saying that the previous person's code sucks. Its like a right of passage or something.

In most of my experiences its not their coding that sucks its their lack of comments or poor commenting that makes their code suck.

Re:Something to note about other people's opinions

[JustinKSU]

Codes is an expression of the programmer's though process. Everyone thinks in a different way. Invariably the last person's code will seem to suck because you have to think differently to understand it. Patterns were developed to create a common ground where people can think about problems in a similar way. Regardless of how pointless and off track a project might be you still should be able to design reusable concise code if you follow the right kind of patterns.

Re:Something to note about other people's opinions

[Anonymous Coward]

I had this problem with a guy that was complaining that my code was full of GOTO statements, used all global variables, and didn't have any comments or subroutines. Bah, it worked so why should he bitch about it?

Re:Something to note about other people's opinions

[Chatsubo]

A lot of the time you find that, while someone is still employed, they do a good job of hiding their mistakes and covering up. It's when they leave that things start to go downhill because now suddenly, someone has to go read and understand their code. Then you realise it's a patchwork of quick fixes and bad design, and decide nice clean rewrite is in order.

At this point you try to justify the change to management, who will "schedule it for sometime next year", since this is not causing them any pain, only you get that priviledge. From that point on, you're stuck with someone else's bugs forever.

Now you're upset and become very vocal about the problems you now have to deal with.

There is a difference between "different" code that works, and bad code that routinely causes problems.

Usually the cracks show about a week or two after the guy leaves. And by cracks, I mean serious, client affecting shit.

Re:Something to note about other people's opinions

[morgan_greywolf]

In addition, I'd have to say that, for me at least, I am my own worst critic. I take a look at code I write sometimes and think "gods, that's awful!" and then show it to another programmer who often thinks it's just fine. On the one hand, I have a tendency to over-comment rather than under-comment, so maybe the comments make my code easier to understand. OTOH, I often code in unorthodox ways. Sometimes it's just to get a little bit of extra performance (like taking advantage of the fact that most languages these days don't always evaluate every expression in a multiple-condition if statement) and sometimes I do it just for the clarity of the code. On the gripping hand, I have to say that sometimes I look at my code and go "wow, that's just lazy and sloppy."

Just because it looks bad to you doesn't mean that it is. It just means you don't feel like it's your best work and maybe it could be better.

Re:Something to note about other people's opinions

[jacquesm]

style is one eternal point of contention (except for python programmers, but they're in a straight jacket), I don't think that it is a part of 'are you proud of your code', that has little to do with what other people think of your code, but everything about what you think of your own code.

When I look at my own code it's a mixed bag. The stuff that I earned the most money with is actually programmed quite bad, some of the most elegant stuff I wrote is sitting unused on the shelf.

I find that in a commercial setting I'm far more inclined to 'cut & paste' to keep moving rather than refactoring just to save the time. Sure, it leads to maintenance headaches down the line and I quite often just scrap stuff and rewrite it rather than figuring out what it did and why. Tools evolve at such a tremendous clip that I don't think the lifespan of code is anywhere near the point where it could be justified to spend say an extra week or two to get an algorithm tweaked to perfection if the next release of the tool or framework is going to have it built in anyway.

Faster machines also lead to sloppy code, I'm running a lot of production stuff on uncompiled PHP, whereas in the past I've rolled out code in assembler because I could beat the C compiler by a couple of cycles on most tight loops.

Times are changing, and that is the biggest 'driver' against 'clean' code, it won't be long before the actual code will start to disappear. For some environments that is already happening.

Oh well, old guys like me will find employment writing for embedded systems, which are about a decade behind the curve.

Re:Something to note about other people's opinions

[noidentity]

Here are some pet peeves of mine involving dealing with other people's code. I don't think many of these are subjective either.

• Header files you can't #include without getting errors because you didn't #include something it requires (but stupidly doesn't #include itself).
• Lots of global variables that are read and written by several modules.
• Header files lacking comments about what functions do.
• Use of non-standard names for types with a fixed number of bits, instead of those from stdint.h/inttypes.h. So they have u16 or int16 instead of int16_t. Or really stupid stuff like uint instead of unsigned int (or just unsigned, which is equivalent).
• Lack of const-correctness. Something like void print_string( char* str ); Huh, does it modify the string? No, then why does it take a pointer to non-const?
• Unnecessary non-portability. Don't use #include unless #include isn't sufficient.
• Internal things put in header files. If it's only used in the module, keep it in the module's source file only! Same goes for not making internal functions static, opening the possibility of clashes.
• Files indented with two spaces instead of a tab, or even just one space. Fortunately this can be worked around with tools.
• Unnecessarily space-taking comments about a function's visible behavior. Things with lines of stars around everything, etc.
• Lack of structure tags, preventing forward declaration. Don't do typedef struct { ... } foo_t; do struct foo_t { }; and a typedef if necessary.
• Macros for integral constants (yes, even in C), since enum does the job and obeys scope (yes, C has different scopes, not just C++).
• Fundamentally, things that aren't highly modular and can be understood and used in isolation. I want to combine modules and have a minimum of complexity increase due to this combination.

Re:Something to note about other people's opinions

[ByOhTek]

Well, it depends. I was helping someone out on an OSS project he had inherited, the original owners wanted to switch programming languages, blaming things on the original language. The guy I was helping had been the new guy on the team, he forked the project, keeping the original language.

Anyway, I could tell the new guys code from the original authors code - there's was messy and hard to follow, for no good reason. I re-wrote a component for him, and he found mine was challanging to follow (I actually wrote a full-fledge parser to handle part of it, and he'd never seen the code for one before), but in the end, he like it because it handled the takes in 1/100th the time of the original authors even less readable code, and 1/10th the time of his code while also being trivially extensible.

Personally, I could have made it faster, but I wanted to keep it flexible, and sensible to read, since others would work on it.

I guess what I'm saying is, part of code quality is personal style, as mentioned in other posts, part of it is the maturity of the person reading the code, and part of it is the quality of the person writing the code.

I've seen code that seems like good quality but doesn't fit my style (gtk, FreeBSD scheduler), good quality and does (qt, pvr250 driver module), and code that just scares me (the original author's code for the project I mentioned above).

My code runs the gamut as well. I have a few things I've put online that I feel are excellent examples of good code, my stuff at work is also good. I have one project that I've been working on at home for a while now, that I sadly need to rewrite because, while not buggy, it is still the slowest, most poorly written code I have ever seen. I'm ashamed that it is attached to my name, but it was certainly a learning experience I hope never sees the CPU of another person's computer.

Re:Something to note about other people's opinions

[RandoX]

Great point. I had a team leader who griped about the quality of my code at my first job out of college. I took it pretty personally until I realized that he was just a pita who complained about the design and execution of everything everyone else wrote. Learned a good lesson that day. Thick skin, in one ear - out the other.

Re:Something to note about other people's opinions

[CmdrGravy]

No wonder, that's a really old fashioned way of doing things. You need to get with the times and functional programming. Personally I do all my programming in functions, often I just need 1 or 2 big functions for a program if I make sure the functions all behave entirely differently depending on the values of the 30 or so parameters I pass to them. It's very efficient and yet still people moan !

CalcCallWaitingTime StripIllegalCharacters CreateInterfaceToACD DrawCalendarOutline may well be quite a long title ( often it's easier to acronymise them before I hand the code over ) but it's amazing the number of loops you can reuse if you have enough switches.

Re:Something to note about other people's opinions

[LiquidCoooled]

I often find passing the function name itself as a parameter helps with loop re-use.
That way you only need to create a single do loop and allow your cx(...) sub (result passed back in the 14th argument unless the 3rd is "E" or above in which case its pushed onto the reference you passed as arg[19 + val(arg4)].

The last guy who tried to use the code was so awestruck with my genius he passed out!

Re:Something to note about other people's opinions

[aldousd666]

I thought you were funny. Apparently the mods didn't yet agree. I'll point back to the fake interview with Stroustrup about C++ in which the author , though not actually Stroustrup, aptly points out with his tongue firmly in cheek that nobody 'REALLY' reuses code. That's not to say they don't reuse patterns of code or anything, but actual non-stock library code is very infrequently re-used, at least in anywhere I've worked == you may get one official 'library' or 'package' that is passed around as 'the corporate API' but I have a feeling that people actually have a lot more than that in mind when they claim to be writing 'reusable code.' Which I'd say, at the end-programmer level, isn't all that common.

Re:Something to note about other people's opinions

[FuzzyDaddy]

That's a great list. I've done #4 myself, before I found out about inttypes.h, but I don't have the heart to go back and fix my old code.

Re:Something to note about other people's opinions

[Atraxen]

For the sake of the wider conversation, let me remind folks that there are still cases where (nearly) every cycle counts. One that comes to mind is is scientific computing (e.g. molecular modeling, !e.g. most analysis). So, if anyone's still missing "ye good 'ole days", there's still a need for 'Shakespearean' code...

Re:Something to note about other people's opinions

[ByOhTek]

most aren't subjective, but the first two quoted definetly are. To make the first non-subjective, change it to a combination of n-spaces and tabs... That's VERY annoying. As for the blocks of stars around a comment, certain patters of multi-lined comments (even with color coding in your editor) make them a lot more visible and recognizable as important, as well as make things look cleaner. It's definetly a personal and subjective preference. The third point - is there a good technical reason for that? I use defines (with very good names) a lot in my code. Who cares if it is LIBNAME_VALUE or LIBNAME_ENUM.VALUE?

• Files indented with two spaces instead of a tab, or even just one space. Fortunately this can be worked around with tools.
• Unnecessarily space-taking comments about a function's visible behavior. Things with lines of stars around everything, etc.
• Macros for integral constants (yes, even in C), since enum does the job and obeys scope (yes, C has different scopes, not just C++).
  

Otherwise, in the following, do you mean things that are highly modular, not things that aren't? The point of high modularity is being able to test, use and even replace the modules independantly. (Note, not trying to be a grammar nazi here, I certainly have no room to talk in that regard, I just want to make sure I'm taking the right meaning out of thise note, or if it has a different meaning that I'm missing).

Fundamentally, things that aren't highly modular and can be understood and used in isolation. I want to combine modules and have a minimum of complexity increase due to this combination.

Re:Something to note about other people's opinions

[rucs_hack]

except for python programmers, but they're in a straight jacket

Ok, Python is very strict in terms of layout, but I wouldn't say it put users in a straightjacket. I'm predominantly a C coder, and I think Python is fantastic. I've started embedding it into my C programs so I can script stuff up to prototype it, then convert to C if required.

The freedom that introducing python scripting has provided is without equal in my experience.

Re:Something to note about other people's opinions

[CastrTroy]

That's one thing that makes VB.Net really nice. They have AND/ANDALSO and OR/ORELSE keywords when working with conditionals. Using AND/OR will evaluate both sides of the expression even when not necessary, and ANDALSO/ORELSE will do a short circuit when possible. It makes the code really clear what it's doing, and lets you do interesting things like "if myObj is Nothing OrElse myObj.objProperty Then". You don't have to remember what it's going to do, because the keyword makes it explicit what's going to happen.

Re:Something to note about other people's opinions

[sm62704]

I've seen time and time again programmers taking over for other programmers' code and saying that the previous person's code sucks. Its like a right of passage or something

You should realise that programming is an art. In art school what you''re referring to is called a critique. It's a good thing. From an old tome I wrote about ten years ago, Steve's School of Fine Art:

Lesson 1: The Critique
        The ultimate in masochism. Your grade depends on the critique. In the critique, everyone in class exhibits their work, and comments on all of it. How good yours looks depends on how bad theirs looks. Each work is scrutinized and ruthlessly shredded by your competitors, whose grades depend on how good their work looks compared to yours. These people are mostly talentless losers, not unlike yourself, who desperately want their work placed somewhere where someone might see it, just like you and Vincent.

      To survive this ordeal, keep your work covered until nearly everyone has their work displayed. Place yours prominently next to the worst piece of crap in the room. While everyone is ripping each other to shreds with pompous, empty, multisyllable phrases, translate what they say into plain english, which will demonstrate to the instructor that you, unlike they, actually understand this gobbledygook. Praise everyone's work with backhanded compliments in such a way that the teacher knows that you know it's crap, while the other students think you're complimenting their work.

      Beat everyone to the punch by being merciless about your own work, especially if you've outdone yourself and have actually produced something that doesn't suck. The teacher knows what you've done right; show him/her/it that you know what you've done wrong.

      Smile smugly when you're ripped. Let your face say "HA! It worked! They HATE it!" (See Insulting an Art Student and Art History, below)

      Lastly, be an attractive woman with large breasts. The heterosexual men and the lesbians will all be trying to get in your pants and won't be hard on your work, the homosexual men will be afraid of being thought of as mysogonistic, and the heterosexual women will dismiss you completely as a total, talentless airhead. This is the only place they won't think of you as a threat.

-mcgrew

Condsidering the subject matter, every comment on this story should be modded "flamebait".

Re:Something to note about other people's opinions

[MyDixieWrecked]

I don't know why this is, I think its just human nature.

one reason for this is that when you pick up someone elses project, you're picking it up from point X where that person coded it from the beginning. Where at their starting point, the goal may have been one thing and was shifted several times over the development timeline and the programmer learned new tricks to keep up with the changing demands and also evolved. This, in addition to different people having different thought processes when coding can lead to challenges when picking up other people's code.

For me, I have the same issue when I look at my code from today versus 6 months ago versus 6 years ago. When I look at my own code from just a couple years ago, I say "this is impossible... I need to rewrite this." It's the same way when I look at code that I did when I was sick or when I wasn't in the zone. Because of this, I've found that putting comments in my code is important. rather than commenting "Recursively loop over directory and process", to actually putting in a paragraph explaining what's happening and why. My code now is probably about half comments for larger projects. Projects that are under 200 lines typically only have a few dozen comments. It's also interesting when you look at your code and you see it's 3500 lines, but you run it through sloccount and realize it's only 1800 lines or less when comments and whitespace are stripped.

Programming is an evolution. It's constantly changing. Your best bet is to familiarize yourself with the code and break it down into a use-case. Program around the way you want the code to be used in the end and it becomes easier to maintain and follow because you've got levels of abstraction and it becomes easier for someone else to pick up later.

Re:Something to note about other people's opinions

[computational super]

But your code, of course, draws gasps of admiration and awe from all who look upon it.

Come on. When was the last time you had anything good to say about anybody else's code? Ever? All programmers say all other programmers are incompetent. And typically, management believes us.

Re:Something to note about other people's opinions

[sm62704]

I found your program and I don't find anything wrong with it, except that it's an endless loop that will eventually use up all the memory and crash the computer.

If I were modding I'd mod you funny, but on the off chance you're really serious (as a couple of child comments suggest), He's bitching about it because he has to maintain it. And GOTO statements? You're programming in BASIC? Now if you'ld said "JMP" statemnents your humorous comment would have been funnier, because uncomment assembly is a real bitch to follow, especially badly written assembly.

Re:Something to note about other people's opinions

[postbigbang]

I still think in cycles, or ticks.

It comes from learning Z80/8080 assembler first, before BASIC, before C. Until that point, I knew a few macro languages.

In my mind, I'm still in a 32K machine, living with the OS, writing strings to hardware ports, and using my own interrupt vector code in concert with the host cycles to get work done.

When I work in C or C++ (heaven forbid #), there's a link list in my mind about array conservation, minimizing strings, using hashing and strict Booleans to get a job done.

No, I'm not an embedded systems coder; I just end up thinking like one.

My comments used to go thru an assembler, and I'd look at the code and try and re-optimize it. And when my code would explode, it would explode to unrecognizable shards of crap until I learned atomization (objects) and resource re-entrance. Now when my code doesn't work, my deadman's switch monitor twigs, which backstreams messages. It makes coding highly involved, but vastly more productive because *I CAN* reuse my code.

I worry more about the OS than my own code; there's so much that's not predictable in operating systems today. They should do more work with smaller kernels and leave modularity out of the kernel. Just my 2c.

Re:Something to note about other people's opinions

[SavedLinuXgeeK]

Thats nice if you are an artist, but most people's code is paid for by XYZ company. Many of these companies have coding standards, most languages used have coding standards, and there are so many proven and accepted design patterns. This is to say that personal flair to coding style is fine, but if you are avoiding conventions, defying standard design patterns, and doing whatever the heck you want, then that is unacceptable.

I know its stated that design patterns should be followed in the parent's post, but that coupled with standard conventions should keep other people's code form 'sucking' because you shouldn't have to think differently to understand it.

--my $.02

Re:Something to note about other people's opinions

[Anonymous Coward]

I primarily work with other peoples code. Our company provides services to companies that come under crunch, or that cannot perform some of the tasks of a project due to lack of experience/knowledge.

A few things I have noticed is that there are many good programmers out there. Some of the code we see is very well written. Here is a simple break down of what we see...

1. Well written, well architected. - Not a lot of this. Apparently there are not a lot of people that can write good code, and good architecture.
2. Well written, poorly architected. - Each round these guys get better at architecture, so they will work out great. Less than half the contracts we work on fall into this category.
3. Poorly written, well architected. - This is usually the case. We see where some senior developer has done great to layout a foundation, then left it up to monkeys to implement.
4. Poorly written, poorly architected. - This is pretty rare. It seems to be only from companies that are young, or that their developers move through a revolving door.
5. WTF! - About half of the code we come across...this is where you see parts of the code that are very elite, elegant, and pleasing. Then the rest of the code looks as though the project was thrown into maintenance way before its time. Usually a sign of a company that starts great, and ends hard. Dumping their good people from one project to the next just to get it started... poor move because these are usually the ones we make most money from because the code base is so screwed up it takes a lot to save it.

My 2Cents

Re:Something to note about other people's opinions

[noidentity]

Macros for integral constants (yes, even in C), since enum does the job and obeys scope (yes, C has different scopes, not just C++).

The third point - is there a good technical reason for that? I use defines (with very good names) a lot in my code. Who cares if it is LIBNAME_VALUE or LIBNAME_ENUM.VALUE?

Not if you have prefixed names like that. I guess I was thinking of headers specific to a program that don't use prefixed names, where enum is preferable.

And yeah, I meant to write this for the last item:

Fundamentally, things that ARE highly modular and can be understood and used in isolation. I want to combine modules and have a minimum of complexity increase due to this combination.

Re:Something to note about other people's opinions

[goatbits]

It has to do with ego. Most programmers have this huge ego thinking that they are the smartest programmer around. It is rare to find a programmer that believes there code could be improved. They also believe that there way is the best way.

A solution to this is to apply simple checks to the code.
1. Does it function?
2. Is it readable?
3. Does it obey functional rules. IE (It does NOT over write memory or what not).

It the code passes these simple rules the code is fine, leave it alone, it does NOT suck.

This does not mean it could not be improved in some way. Open discussions in code reviews could enlighten every one. (Please leave your ego at the door).

Re:Something to note about other people's opinions

[incorporalis]

30 parameters!?! You must really hate your co-workers.

Re:Something to note about other people's opinions

[ByOhTek]

I have a library I'm working on, and I use LIBRARY_SUBLIBRARY_ as a prefix for EVERYTHING, just as good anti-collision-in-C practice.

It got to be a pain in the butt to use the library with that, so I added an optional LIBRARY_SUBLIBRARY_QUICKREF check at the end, which would make a define for all of the library calls without the LIBRARY_SUBLIBRARY_ prefix if the QUICKREF is defined. Well, except for a few that wouldn't make sense (a couple of the libraries have their own free functions, which I decided shouldn't bell allowed to be called as free(), for obvious reasons...)

Re:Something to note about other people's opinions

[Tesen]

One has to ask also, is it the code that breaks or is it the underlaying system the code is written around? I left my last job in a hurry (was about to kill my boss... seriously, that bi-polar bitch just generally pissed me the hell off to the point I was about ready to come in with a tactical nuke... no really kaboom ya bitch!).

Anyhoo, the systems I was tying together were old mainframe systems with SAP and then my own SQL backend. So you'd get data that you had to match between legacy and SAP, then of course the code would not "break" but you'd need to add some logic to massage the data. Of course, I left and suddenly the data issues were caused because I could not code, it had nothing to do with an ever changing difference between a legacy system built 25 years ago and an SAP implementation that still does not work right.

My basic response to one critic I saw after I left was: "How come they got the data when I was there and now they can't get it because I am not?" Those that can do, do... those that can't just bitch and moan.

I got stuck supporting a very old delphi application in another job, it pulled in flat files from another system daily, often these files would not show up due to batch jobs failing. I had MQSeries setup to pull in the same legacy data this app needed for some other systems. The first thing I did was to populate the delphi application (I was not given the time to convert it to a full SQL backend/rewrite it :P) paradox tables from a SQL DTS package. My team members said the previous coder "sucked" because of the flatfile populating, they were in error - he did not suck! That mechanism for data updates was the ONLY method available to him in 1997. People judge way to quickly, I think it is a matter of ego stroking to make them feel better about themselves.

Tes

Re:Something to note about other people's opinions

[Fred_A]

Personally I do all my programming in functions, often I just need 1 or 2 big functions for a program if I make sure the functions all behave entirely differently depending on the values of the 30 or so parameters I pass to them. Makes sense. All you usually need is initStuff() and doStuff(). Saves having to think up function names too. Saves a lot of time.

Re:Something to note about other people's opinions

[nickyj]

I beg to differ. Most of my work is in Perl and I work with one other person. Most times we are working on our own programs which work together eventually. We have different coding styles (helps us know who wrote what) and we often have to look at and adjust each others code. We usually bust on each other for mistakes and laugh at some of the comments we put in. Glad clients never see our code :)

Re:Something to note about other people's opinions

[Tom Cully]

Q: How many developers does it take to change a lightbulb?

A: 10. 1 to change the bulb, and 9 to say "no, I would have done it like this..."

For me, this is part of the "Is programming is a science or an art?" argument. You can send a person to Art College and then have them paint for 10 years, and even then they won't necessarily produce masterpieces. Sometimes we comment like that on code we've taken over, because it really is awful...

Re:Something to note about other people's opinions

[Coryoth]

style is one eternal point of contention (except for python programmers, but they're in a straight jacket) I would hardly call being forced to actually indent your code a "style straight-jacket". Try coding in Eiffel sometime -- there aren't requirements on indentation, but there's pretty much "one way to do things"; Looping constructs? If we make a single general one if should be good enough for everyone; and so on. On the other hand, pretty much all the Eiffel code I've ever had to read has been impeccably clear and easy to understand, with very consistent style across a wide variety of different authors. If I had to inherit a software system to maintain, I think I'd be very happy if it had been written in Eiffel (or Ada for that matter, it seems to promote a similar level of clarity and consistency).

Re:Something to note about other people's opinions

[Mr2cents]

I think part of the problem is that programmers lack the courage to just think. I recently had a programming problem that I thought two weeks about. That's go to work, think, write down some key ideas, pitfalls, things to do etc. on a piece of paper and go home. After these two weeks I had three A4 papers with some text scribbled on it. Then I spent one week coding, and when I finally tested it it worked from the second time (one small bug found).

In my experience, not everybody dares to work this way. It is a bit embarrassing if your boss enters your office and you're just leaning back in your chair, day after day. But on the other hand, if they wanted someone who would always seem busy, they hired the wrong person; they should have gone for a typist. Thinking is an important part of a programmer's job.

A second advice would be to keep abstractions as simple as possible. Think "What do I need and what API do I need to do that?". If you can get away with an API with only an init function and a "worker" function, then be my guest! K.I.S.S. is very important. Again, to make things as simple as possible requires a lot of thinking.

And while you are thinking it helps to have enough experience to have a "mental compiler". I can write and test code in my head so to speak. But that is something you only get after many, many years of intensive programming.

Re:Something to note about other people's opinions

[gardyloo]

It the code passes these simple rules the code is fine, leave it alone, it does NOT suck. That's because it puts the lotion on the skin, or it gets the hose again.

Re:Something to note about other people's opinions

[daem0n1x]

Functional? Bah! That's pretty old-fashioned. Why don't you move to object oriented instead?

All my programs consist in a class. I create a lot of static methods that call each other to perform the purpose. All methods return an integer with an error code and the caller can then check the results in static variables. Easy, no?

The coolest thing about OO is that, when I create suclasses I can, with if statements, know my type, and then execute code according to it. OO rocks!

Re:Something to note about other people's opinions

[Anonymous Coward]

To alleviate the 'art' and subjectives elements measure your code empirically which is as easy as run open source tools for a language such as C.

1. Gcc Compiler warnings to MAX
2. splint to the MAX
3. Run McCabe analysis - that will tell you how readable your functions are.
4. Run Valgrind or similar .
5. Use doxyegn, list to its warning about undocumented code.
6. Use the profiler to check that the finished code only spends time where it makes sense that it should

If you respond to everything that barrage reports, your code will at least be good to an independent repeatable standard.

Re:Something to note about other people's opinions

[ribuck]

I've seen time and time again programmers taking over for other programmers' code and saying that the previous person's code sucks. Its like a right of passage or something.

It's not just programmers who do this. Try asking a builder or plumber (in the UK, anyway) to modify something built by someone else. Usually, the first thing they'll do is suck air past their teeth and say "Who did this then?"

Re:Something to note about other people's opinions

[cras]

Who cares if it is LIBNAME_VALUE or LIBNAME_ENUM.VALUE?

Enums are visible to gdb, macros aren't (at least by default, not sure if there's some option). Also named enums make it possible for compiler to do type checking to make sure you're not mixing enums into wrong variables accidentally. Unfortunately gcc doesn't give warnings about those.

Re:Something to note about other people's opinions

[basingwerk]

There's a lot to be said for that. A lot of the most well designed, perfectly structured software ever written gets scrapped, yet much of the actual working software is, as you say, full of GOTO statements, uses global variables etc. If a thing works, there's a lot to be said for it. You can always get people to write newer, better structured parts for it later, but most of all it has to work.

Re:Something to note about other people's opinions

[Zebedeu]

About this one:

Header files you can't #include without getting errors because you didn't #include something it requires (but stupidly doesn't #include itself) Coding mantra at my university (as in, I heard it from more than a few teachers) is that you should never have your includes in header files.
Of course this always sounded strange to me because then you have to always remember what includes are required for that particular header. I think it had something to do with avoiding multiple header declarations, but I though that's what the #ifndef XXX_H #define XXX_H technique was for.

So what I'm asking is: why have I always heard that #including in your headers is a big no-no?

Re:Something to note about other people's opinions

[SilentBob0727]

Over-commented code (the kind where there's 2-3 lines of comments for every one line of code -- not every closing brace needs a reminder that we're exiting a code block, thanks!) is pretty awful too. I've met people of the agile variety who insist that well-written code needs no documentation: that if you carve your code up into small, tight, appropriately named classes and methods it becomes obvious what your code does and your code becomes "self-documenting", and I've met people who won't even look at code unless every single line is commented telling them precisely what it does, so "int i = a + 2;" has to have a comment above it saying "// create a signed 32-bit integer variable, i, and assign it two more than the value of a".

The former is wrong because while it's great that we now know what each little piece of your code does, it's still a challenge to see the forest for the trees in all but the most trivial cases (it also means that after several refactors you end up with a whole lot of miniature orphaned functions littering up your code that are never called and that do nothing but that everyone's afraid of deleting). A good method name doesn't tell the reader why the method is there or what its intended usage is. The latter is wrong as well, because suddenly naturally flowing code is broken up to the point where comments become a distraction and make the code harder to read (incidentally, this is why I started using justified end-of-line comments... it helps with the distraction).

You should always comment your classes (or your data structures if you're using a non-object-oriented language) -- state the reason they exist, what requirement they fulfill, their role in the application, and any caveats to using them. Comment your constants, class and instance variables if it's not bleedingly obvious from the class description what purpose they serve.

Comment your public methods! Your public methods are essentially the exposed API into your code, so if you want your successor reusing code you wrote rather than writing his own that does the exact same thing, it had better be absolutely clear how it is to be used. At a minimum, this should include what the method is there to do, a detailed description of each parameter to the function, and any constraints on the parameters, side effects of invoking the method (Does it write to any files? Set any external variables? Allocate or free any memory?), the range of values that can be returned, a description of any special return values, and any exceptions that can be raised when calling the function. Comment your private methods as well, though with your private methods you may be justified in just explaining why the method is there.

And for the love of God, don't comment your private variable accessors unless they get or set in an unusual manner. And you don't have to comment constructors that just assign parameters to instance variables.

Finally, while those agile guys are right in that your code really should have a natural flow and speak for itself, you should still comment your runtime code. Longer functions should be divided up into "paragraphs" with comments stating what's about to happen and how the current state contributes to the overall goal of the function. If your functions have extremely clean divisions of functionality, consider breaking them up into smaller private functions unless you're concerned with every last ounce of performance and can't afford the 10-20 cpu cycles necessary to do a function call (or declare the methods as inline). If you're doing something in a manner that's unorthodox or not immediately readable or that will make someone reading your code go, "what the hell?", either rewrite it (=D) or comment it to justify why you feel it was necessary to do it that way.

Automated unit tests can also be a good supplement to well-documented code, as they give natural examples of code usage and can serve as tutorials for people trying to learn your code. Often this displays intent a lot better than comments can, since doing is often more effective than saying.

I find people are more concerned with whether code is commented "enough". I think it's better to be concerned not with the amount, but the quality of comments.

Re:Something to note about other people's opinions

[Intron]

You forget Err(), the routine that traps all error conditions so you only need one dialog box which says:
"You must have done something wrong since my code is pfect".

Re:Something to note about other people's opinions

[SilentBob0727]

So you write in assembly then?

Re:Something to note about other people's opinions

[raddan]

No kidding. Have a look at this:

#include<iostream>
#include<vector>
#include<algorithm>
using namespace std;

int main()
{
vector<double> v;

double d;
while(cin>>d) v.push_back(d); // read elements
if (!cin.eof()) { // check if input failed
cerr << "format error\n";
return 1; // error return
}

cout << "read " << v.size() << " elements\n";

reverse(v.begin(),v.end());
cout << "elements in reverse order:\n";
for (int i = 0; i<v.size(); ++i) cout << v[i] << '\n';

return 0; // success return
}

The first time I saw that, coming from a C background, made me think, "This is simple?!" Of course, now that I've been programming in C++ for a couple years (per requirement of my CS department), I have to say it's not so bad. Maybe not the way I'd approach the problem myself, but it does have a certain conceptual elegance, even if the code itself looks like puke. Bjarne Stroustrup wrote this, BTW.

Re:Something to note about other people's opinions

[AnonymousRobin]

Shakespeare Programming Language

Re:Something to note about other people's opinions

[plopez]

I once spent 18 months thinking about a problem, a hard problem. Fortunately it wasn't needed immediately as we were using a transition approach to rolling out an in-house suite of programs.

Re:Something to note about other people's opinions

[Vellmont]

Come on. When was the last time you had anything good to say about anybody else's code? Ever?

I've seen lots of good code. I've also seen some incredibly horrendous code, on multiple different levels. Until you've seen extremely poorly architected code, it's hard to appreciate just what bad code is.

Does the good code have flaws in it? Of course. Does the good code always do things the way I would have? Of course not. Good code isn't code that's perfect. The distinction has more to do with how maintainable the code is, how secure it is, etc. Basically the big picture and not individual lines, functions, objects, etc.

Re:Something to note about other people's opinions

[Greyfox]

Programmers always tell their managers that the code they inherited needs to be rewritten. The programmers that left often got in a hurry or didn't completely understand their requirements or the business logic of the processes they were coding to support. Maybe they weren't great designers when they started working on the project and sometimes their design skills improve and sometimes they don't.

But odds are you don't really understand the business logic you're coding to support either, especially if you're new on the project. That means that you're going to make mistakes as well, and you might get in a hurry and cut corners trying to fix them.

No system is perfect, and your understanding of the requirements and the requirements themselves will evolve over time. Perhaps you will even find justification for some of the atrocities committed in the code. Sometimes some really bizarre code actually had to be that way. And the show must go on even if you want to be off rewriting the code somewhere. The people you're supporting are going to be using the old system while you're off coding for months and months.

So managers tend to be suspicious when a new hire tells them that the code is a crock of shit and it stinks. They've been through that before, and each new programmer always seems to crap a different crock of shit and then leaves for a higher paying job elsewhere.

If the system works at all, however, you can usually identify subcomponents where work occurs. You can usually iteratively improve the design of the various subcomponents and how they interact together. It's a process that can take years for a particular project but it's much easier to justify evolving the design in small pieces. The resulting system might not be perfect, but it should be better.

Re:Something to note about other people's opinions

[Atraxen]

Doh! That hurt my soul.

Re:Something to note about other people's opinions

[Antiocheian]

"int i = a + 2;" has to have a comment above it saying "// create a signed 32-bit integer variable, i, and assign it two more than the value of a". Without a comment on the purpose of i ?

Re:Something to note about other people's opinions

[cruppstahl]

Yes, these things are all annoying, no doubt.

However, with enough experience, they don't matter. Look at global variables: sure, it's not a clean design. But they are easy to understand - just grep for them, look what they do and you're able to understand the code. Same applies to most of the other items you've listed.

For me, good code means that somebody else is able to understand and modify my code in a very short time.

And therefore i really prefer to work with plain, but ugly C code instead of fancy, over-designed, over-architectured C++.

Try to understand a global variable - easy, if you've a bit of experience. Try to understand code with 200 classes, and each one has overwritten operators - this is hell.

Re:Something to note about other people's opinions

[cbart387]

Agreed. There's plenty of areas that still need tight, efficient code. Cryptography, Operational Research, Compiler Design are ones that come to mind from my limited experience. Certain parts of the OS, that are use many times, should be efficient. I think the parent of my parent is thinking of the hyped technology, with all the cool buzzwords.

Re:Something to note about other people's opinions

[OneSmartFellow]

Surely this is all moot with the advent of .NET and dynamic compilation at our fingertips. Now, nobody needs to worry what your code does, because all it does is run

while(true)

{

    string compile_me = get_input();

    execution_unit exec = compile(compile_me);

    exec.execute(get_args());

}

Re:Something to note about other people's opinions

[mwvdlee]

So what I'm asking is: why have I always heard that #including in your headers is a big no-no?

Everybody does it, from companies big to hobbyists small, so therefore a university cannot possibly allow it.

Re:Something to note about other people's opinions

[ultranova]

And GOTO statements? You're programming in BASIC? Now if you'ld said "JMP" statemnents your humorous comment would have been funnier, because uncomment assembly is a real bitch to follow, especially badly written assembly.

Of course you could get the best of both worlds by having your BASIC program modify the BASIC interpreter on the fly with the poke command. Gentlemen, I give you... ASSYMBLIC !

Re:Something to note about other people's opinions

[Anonymous Coward]

That's not been my experience. As a support developer, I've mostly worked on existing code rather than writing code from scratch, and have substantial experience in understanding other people's code.

Although different people adopt different standards, there are plenty of aspects which mark a careful programmer from a less careful one.

There have been a few programmers that I would happily work with again, and would recommend for any development position. There have also been developers who I would never want to work with again, because their code was terrible - to the point that it was agreed that if their code had to be worked on that it was OK with the management for the standard approach to be to throw out the existing code and write replacement code from scratch.

Some issues can be as much a lack of knowledge of the programming language - using slightly awkward loops and other code structures to achieve the goal (e.g. lots of if statements where a select statement may be cleaner), wasting memory or cpu resources with inefficient methods and so on. This can be excused among more junior members of a team, but more senior developers should be familiar enough with common issues to ensure that they do not become a problem later.

Other issues with code are a failing in basic practices, such as using inappropriate variable names. It's not been uncommon to see VB code using default names for text boxes, etc, which inevitably makes it harder to know what value the variable should contain without looking at more code.

Code structure is a matter of style, and there are different approaches, and it's difficult to say one is right and another wrong. However, depending on the language there can be failings in the approach which suggest laziness more than a deliberate choice of style. An example would be using On Error Resume Next in Visual Basic - it is necessary at times, and sometimes you may want to ignore an error for a period, but all too often you'll see it used to just skip proper validation, and not cancelled afterwards, so that debugging and so on is harder later on as the error is not raised or handled properly.

Logical errors can also be quite apparent, sometimes. Using fixed arrays which will fail when the system goes past a certain number of entries, when it is likely that this will happen at some point. Or other fundamental errors that don't follow the requirements of the project or specification. They crop up in code, but should be picked up in testing, and consistently missing logical errors suggests a problem with the development approach.

So while it may be hard to understand how someone thinks and therefore how some code works, that's not a reason for slating someone else's code. There are, however, plenty of times where code can be rightly slated for not being done properly. Sometimes there are changing requirements, and a new employee can end up with the Frankenproject so their code ends up a mess, but part of a professionals job is to state when a quick fix will no longer be suitable, and that a more complete replacement is required. Since we are so keen to consider ourselves 'software engineers', we should take a similar effort to not just write code, but to ensure that any work we do is fit for purpose.

Re:Something to note about other people's opinions

[SilentBob0727]

Comments of the every-single-line variety have a tendency to simply restate what the upcoming line does. Not terribly helpful.

Re:Something to note about other people's opinions

[optilude]

you just described the reason why Java was invented. Not because it is technically superior but because it makes team programming easier and less error prone.

Re:Something to note about other people's opinions

[noidentity]

Is C a necessity? In C++, that's an absolute breeze:

namespace library_sublibrary
{
        const int foo = 1234;
}

int bar = library_sublibrary::foo;

Too long?

namespace ls = library_sublibrary;

int bar = ls::foo;

Still too long?

using library_sublibrary::foo;

int bar = foo;

Want to bring all the names into scope, not just foo?

using namespace library_sublibrary;

Re:Something to note about other people's opinions

[cayenne8]

Wow...do people out there really have TIME for coding methodologies, reviews and the like? Most of the time I've done it...is get it out of the door yesterday, and make it work however you have to.

I started looking up the terms being thrown around here lately for coding...'agile', 'cowboy', etc. I'd never really heard the terms much.

Do places really have all this stuff laid out for programmers? Standards? Naming conventions, development cycles? How do they find the time for that? I've never really seen timelines that allowed for that much time and long deadlines before.

I've heard the theories, but, have never really seen them in practice. How many out there do all of this...or just part of it, or moreso, pay it lipservice, and jump in there and write as you have to to get it working and out the door to meet a deadline?

Re:Something to note about other people's opinions

[mini me]

# Les gars sont agiles droite. Si le code est écrit Bien, il va parler pour lui-même.
# Il n'ya pas besoin de Double emploi avec ce que dit le code dans une autre
# langue (Anglais). C'est peu comme votre commentant Anglais paragraphes d'une
# interprétation française. À moins français est votre langue maternelle c'est
# juste aller Pour obtenir de la manière et de rendre la lecture de la même Anglais
# Plus difficile. Comme un programmeur, c'est mon travail d'être Parle couramment le
# langage de programmation de mon choix. Reading Code devrait être aussi simple que de lire un livre.
The agile guys are right. If the code is written well, it will speak for itself. There's no need to
duplicate what the code says in another language (i.e. english). It's kind of like commenting your
english paragraphs with a french interpretation. Unless french is your native tongue it's just going
to get in the way and make reading the english even more difficult. As a programmer, it's my job to
be fluent in my programming langauge of choice. Reading code should be as easy as reading a book.

# Cela dit, parfois, vous avez vraiment à écrire Quelque chose d'anormal, et, dans ce cas, vous devriez
# Commentaire. Toutefois, ces cas sont rares Entre.
That said, sometimes you really do have to write something abnormal, and in those cases you should
comment it. However, those instances are few and far between.

Re:Something to note about other people's opinions

[oliverthered]

hmm.. I tend more to the Agile way typically my comments look like: // Add a beginning and end of line match (this may be a bad thing? still needs to be thought about/worked out properly)
#warning "This call fails in .net 1.1 because of a bug in .net 1.1, the easiest way around it is to use .net 2"
I also put short comments in about each 'paragraph' block in the code and plenty of TODOs where work still needs to be done or extra features could be added.

I do also write fairly full design documentation as I go along with every problem I come across and the possible and chosen solutions.

I find that a lot more helpful then any comments in the code as it gives me the big picture and tells me why things were done and other ways that they could have been done.

I can also usually drop any project and pick it up again months later and quickly and easily pick up where I left off.

If you really want to find out what side effects a function has or how everything hangs together there are tools to do that (or they can easily be written) and they will be more accurate and less misleading than any comments someone can write.

Re:Something to note about other people's opinions

[somersault]

It does seem pretty simple, what's the issue? o_0 I dont even use C++ that often but it's pretty obvious that the program reads in a bunch of user inputs and prints them out in reverse order.. I consider the code that I write myself to end up a lot more confusing There was one particular function that generated a set of random paths around a graph in a way that no matter what junction you started from, you ended up at a goal node (was for some Counter-Strike bots before they got those crappy commercial ones). I managed to screw it up somehow and had to rewrite it because I couldn't even tell what was happening with my code anymore, but the second time I wrote it it was a *lot* cleaner, because I'd spent a lot of time on it already and managed to see ways that I could simplify the code. For any decently complex algorithm you write, the code probably *will* suck the first time round unless you have done something similar before.

Re:Something to note about other people's opinions

[ByOhTek]

C is necessary because almost everything (language) can interoperate with it fairly easily. It can be more of a challange if you want to get C++ interoperation.

Re:Something to note about other people's opinions

[technomom]

Right up until someone decides to write a Web 2.0 application. Then they use abominations in Javascript like....

yourWidgetFunction : function()
{
        somebodyElsesWidget.somefunction = function() {
                        eval(someOtherVariableThatContainsJavascript);
        }
}

I see that everyday now. Makes me long for Java. Good luck debugging this crap.

Re:Something to note about other people's opinions

[FooAtWFU]

But your code, of course, draws gasps of admiration and awe from all who look upon it.

Come on. When was the last time you had anything good to say about anybody else's code? Ever? All programmers say all other programmers are incompetent. And typically, management believes us.

Last time I had something good to say about someone else's code was... probably Friday. If not that, then Thursday. It was a dynamically-programmed delegation snippet that conditionally sent about a dozen methods somewhere else in about 5 lines. Scary-awesome.

I work with some very skilled people, and because we do the whole 'extreme programming' pair-programming deal, I get to see some pretty decent stuff in there every single day. And I know I'm about ten times better of a coder because of it...

Re:Something to note about other people's opinions

[SavedLinuXgeeK]

Yes. Every project I have worked on has had design standards, coding standards, and peer reviews. Yes there were tight crunches on time at many moments, and the quality of code does suffer at those points, but overall the code lives up to the standards and is better for it. It is easier to maintain, debug, update, refactor etc. because it is well designed and implemented. I very well could be an anomaly but I have to believe that in order to ensure that a system requirements were meant (in the form of Ilities) you need to have broad control over the code (how design decisions are developed, and enforced).

Re:Something to note about other people's opinions

[kisrael]

Bad code looks bad.

Good code looks natural and obvious.

Or it looks bad because you don't understand all the constraints it was written under, from extra requirements (though those should be documented), to time constraints, to hidden gotchas -- sometimes you might miss the whole paradigm it's aiming for, and if it's not well-explained, you're going to think that it's awful. (Hell, even if it's documented, when you come into a codebase that you didn't hear the arguments for and against, and couldn't put in your two cents... it's going to feel bad. Or if a system started being super-flexible because they wanted to keep options open, and then by the time you get your hands on it, all the flexibility is gratuitous and just makes things wobbly...)

Re:Something to note about other people's opinions

[Anonymous Coward]

Have to agree with the opposite of some of those :) People using "unsigned" without "int" afterwards (an adjective is not a noun). People using those ugly "uint64_t" types from stdint.h instead of following our local coding standards which allow for far less typing. People who reiterate concerns about C programming style from the 1980s which were rendered unimportant with C++.

Re:Something to note about other people's opinions

[TemporalBeing]

Two points...

Don't forget about header include guarding - as mentioned by this comment, for example. One of the reasons I really hate using Microsoft's headers - they don't do include guards so the order of the includes matters; they use the #pragma once guard, which is not really a guard as you then have to get the order right, and God help you if you have to include your header before another header that ends up creating a circular loop due to the #pragma once guards.

Lack of structure tags, preventing forward declaration. Don't do typedef struct { ... } foo_t; do struct foo_t { }; and a typedef if necessary.

Well...except that when working with Strict C and a compiler such as Microsoft's VS 2005 C compiler, you have to typedef the struct. Annoying but required or else you get all kinds of errors. Been there. Done that. And technically for Strict C, you should be. In C++, however, you are right, but why break the backwards compatibility?

Also, don't forget lack of comments in general either.

Re:Something to note about other people's opinions

[lymond01]

hmm.. I tend more to the Agile way typically my comments look like: // Add a beginning and end of line match (this may be a bad thing? still needs to be thought about/worked out properly)
#warning "This call fails in .net 1.1 because of a bug in .net 1.1, the easiest way around it is to use .net 2"
I also put short comments in about each 'paragraph' block in the code and plenty of TODOs where work still needs to be done or extra features could be added.

I see // and # and a quoted line. I can't understand your commenting. Your code sucks.

Kidding. ;-)

Re:Something to note about other people's opinions

[Anonymous Coward]

Files indented with two spaces instead of a tab, or even just one space. Fortunately this can be worked around with tools.

This is a pet-peeve of mine -- but in reverse. 2 spaces is fine, there's only 80 columns on a standard tty. I also have code where I used single space indenting because it makes the code more readable with a 76 char line wrap. So I'd say this one is subjective. For those of us who use Vim or often work via SSH, white space can make the code more difficult to work with.

One thing that isn't subjective is tabbers who also mix in liberal use of spaces; those dirty good-for-nothing bastards!

Re:Something to note about other people's opinions

[networkBoy]

At my old job we re-used code.
It was written in Borland C 2.0, shoved into 3.0, dragged across to Visual Studio 6, then keelhauled into 64 bit support (from 48 bit initial functionality). We re-used that codebase for every project, tweaking and modifying, forking where appropriate per product family. Management asked what it would take to make it more maintainable and myself and the one other developer still with the company said: 8 months of dedicated time for one of us, with guaranteed time for code reviews of 2 half days per week for the other developer to provide a second set of eyes. Naturally that didn't happen. FFwd a year and the division is being split from the parent company with > 30% layoffs. Upper management decided who went and who stayed with a rather broad brush. Since I was technically "maintenance" and the other developer was old enough to retire we were both cut (she got a carrot to volunteer to retire). So who is developing and maintaining the code now? My old boss. Less than a month has gone by and I'm already getting "helpdesk-ish" calls on the code. Once they are fully split from the parent company (for which I am still employed, but in a different devision now), my consulting rate will kick in, and boy will it be nice.

Moral of the story: When code *is* re-used, it usually gets ugly. A clean re-write is not always a bad idea, and if your devs are asking to be allowed to re-write something you should let them before you can them...

-nB

Re:Something to note about other people's opinions

[coaxial]

Right-o. Too many people don't comment their code at all. I've spent a day before just commenting other people's code, just so that I could begin to know where the bug was. Don't make me figure out what your for-loop is doing. Just tell me. You want your code to be as clear as possible, and comments make the complex clear, and the obvious more obvious -- which is good, because it's obvious that what is obvious to one is not always obvious to another. ;)

Re:Something to note about other people's opinions

[SilentBob0727]

This is a false analogy. Human language is symmetric in that it is designed to be produced and consumed by a human. Programming languages, on the other hand, are asymmetric in that regard. As such, reading a computer program requires a certain amount of aptitude that's better suited to a computer -- for example, tracking the entire program state at any given time. Granted, you only have to track the state that's relevant to the current context, but recursively switching contexts (see function call, go look up function, finish reading function, go back to function call, keep reading previous function) is something a computer does well and a human doesn't do well.

Also, humans tend to read left-to-right, top-to-bottom. Any worthwhile program is filled with loops, branches, conditionals, calls, recursion, etc. As the program size grows, it becomes very difficult to sit down with the uncommented code and just read it, and actually take away the general gist of what was just read. To do so requires several sessions of hard concentration and focus, and time to reflect on and digest how it all works together. Well-structured, well-written code can only go so far.

Comments, in many cases, make up for that lack of aptitude. It's not restating, it's clarifying what the code does so as to make it less likely for the reader to get lost and help speed up the learning curve.

Re:Something to note about other people's opinions

[cayenne8]

"I was tying together were old mainframe systems with SAP and then my own SQL backend....I got stuck supporting a very old delphi application in another job, it pulled in flat files from another system daily, often these files would not show up due to batch jobs failing."

Were any of these jobs at Acxiom?

Re:Something to note about other people's opinions

[Hoi Polloi]

Just make sure to check the name of the code's author in the comments in case the person you're saying it to is also your new boss.

Re:Something to note about other people's opinions

[GooberToo]

I have seen some bad code before. I've also seen a lot of code that's different from how I would write it. That doesn't make it bad. Good code is good code.

The mark of a good coder is always one which can detach him/herself from their ego. This is very rare. All too often coders slam code for the sake of justifying their sad existence. This code is bad therefore I'm a better, more valuable coder to the company, because I would never write code like that. Generally I find those that are most venomous are the worst coders of the group. I figure deep down they know then and this is their pathetic attempt to justify their paycheck.

If coders spent as much time supporting their comrades and improving their own knowledge as they do tearing down each other, the state of the art would be vastly improved.

Re:Something to note about other people's opinions

[Hoi Polloi]

Usually what looks like bad code has a story behind it. You find out it was written over the course of years by different people, couldn't be updated to keep ($paying$) users of old versions happy, doesn't use new features because it was written before they came out, no time to update old code, used ugly kluges to get around limitations in the OS/hardware/other code, etc. Once you learn the reasons you still think it is ugly but you understand why.

Re:Something to note about other people's opinions

[Nevyn]

Files indented with two spaces instead of a tab, or even just one space. Fortunately this can be worked around with tools.

This is at best personal opinion, and AFAIK all the actually testing done on this shows that 1 space indentation isn't enough, which is why 2, 4 or 8 spaces are the norm. My opinion is that TABs should never be used for indentation, as none of the tools will multi line things up correctly (Ie. you need to use TABs to the start of the original line, and then space to line up). Also TABs and spaces mixed are the spawn of satan, and given that we can't get rid of spaces getting rid of TABs is the only sane option.

Macros for integral constants (yes, even in C), since enum does the job and obeys scope (yes, C has different scopes, not just C++).

What people call C is really two languages, and the pre-processor doesn't understand enums so that's a major reason to use macros instead. This is esp. useful when you are defining an interface and need to expand it (Ie. #ifdef FOO /* code for older interface where FOO doesn't exist */). You can mostly get around this by using enums and then defining macros of the same name to the enums, but that doesn't always work ... or you can just not use enums because noone else does either.

Fundamentally, things that aren't highly modular and can be understood and used in isolation. I want to combine modules and have a minimum of complexity increase due to this combination.

While that's a nice goal, it's really really hard to do well. Making a shared library that does X is at least 10x harder than just doing X IMO. ... making it work well can be even harder. And the maintenance burden is probably closer to 100x harder, unless you take the retarded route like OpenSSL and cause everyone using your API massive pain.

Re:Something to note about other people's opinions

[Sparks23]

On the agile, small-functions stuff, there is a reason that agile programming is mostly meant for languages like Java; most agile teams have testing harnesses which will tell them when a small function is no longer used, or how many places a small function is used. This does not solve the 'forest for the trees' problem, but does at least eliminate the fear of deleting small orphaned functions.

I do otherwise agree with all your points; the best place is a middle ground between agile's self-documenting and the traditional ZOMG COMMENTS. At my (non-agile) workplace, we document at the top of each function what the function does and what it takes and returns, as well as documenting any complex or unintuitive block of code within a function. (The ideal would be to avoid unintuitive code entirely, of course, but this is not always possible when dealing with things like VoIP goo.)

Re:Something to note about other people's opinions

[Chatsubo]

Flame away if you want. I never said my code was perfect, or that this was the case for every person that left. Some people leave and you wonder how the hell you could ever be as good as them.

The point is that there ARE people who leave this kind of way. "Well, he thought different" doesn't cut it if the code doesn't WORK.

Note again, I'm saying code that doesn't work, not merely "code I don't like". Code that literally affects clients negatively. Do I write code like that? Yes. But it takes a big man to go to the manager and say: "I'm sorry, when I wrote that, I didn't understand the problem as much as I would have liked. I fucked up. Please let me fix it.". Instead of writing a quick fix and hiding the problem.

And yes, I have done that (admit my errors) and I will do it again. I considder programming an art that comes with time.

Re:Something to note about other people's opinions

[Chatsubo]

I've seen similair. Once I was tasked to "fix" something another developer had written, with management bad-mouthing him quite badly before giving the project to me. I ended up discovering that his code was fine and that the problem was in an underlying library.

Re:Something to note about other people's opinions

[noc007]

Whoa. Do you and I work at the same company? That's exactly what's going on here.

The sad thing is, the people here that do leave are generally burned out from the ever changing and crazy demands from the C-level executives.

Re:Something to note about other people's opinions

[Anonymous Coward]

>> I don't think many of these are subjective either

- Header files you can't #include without getting errors because you didn't #include something it requires (but stupidly doesn't #include itself).
I agree, but on the other side you slow down compilation a bit at the 6876823 inclusion of stdlib.h

- Use of non-standard names for types with a fixed number of bits, instead of those from stdint.h/inttypes.h. So they have u16 or int16 instead of int16_t. Or really stupid stuff like uint instead of unsigned int (or just unsigned, which is equivalent).
In many places I worked it was mandatory to use a different naming using custom typedefs/defines

- Lack of const-correctness. Something like void print_string( char* str ); Huh, does it modify the string? No, then why does it take a pointer to non-const?
Good style, but pretty useless because of casts, etc. Besides, nobody gets it right and it hurts productivity more than how much it improves it.

- Internal things put in header files. If it's only used in the module, keep it in the module's source file only! Same goes for not making internal functions static, opening the possibility of clashes.
pimpl is less efficient, and quite an useless burden apart from specific cases. Take it as a defect of C++.

- Unnecessarily space-taking comments about a function's visible behavior. Things with lines of stars around everything, etc.
What's unnecessary is quite subjective.

- Macros for integral constants (yes, even in C), since enum does the job and obeys scope (yes, C has different scopes, not just C++).
Constants are not an enum. It's not clear unless you know it's used that way. Subjective.

- Fundamentally, things that aren't highly modular and can be understood and used in isolation. I want to combine modules and have a minimum of complexity increase due to this combination.
In some cases, singletons can give great improvements to an architecture. Flexibility for future changes. Modularity is a constraint, you should know when to relax it.

Not that I don't agree with you on many points, but most are subjective even if you don't believe it.

Re:Something to note about other people's opinions

[Doctor Crumb]

I agree that the previous guy's code is always worse than your own (I fully expect my replacement to curse my name), but in at least my current situation, I can point at solid evidence to support my claim. Examples:

* magic numbers throughout, like using 99 to indicate some sort of failure or returning -6 on a particular sort of error
* lack of documentation on said magic numbers, leaving the next coder to figure out wtf they're for
* variable names like "string"
* a series of variable names called "email1", "email2", "email3", and so on
* global variables *everywhere*.
* 500 line function named "process".
* display code mixed with business logic mixed with DB calls
* no code branching, files were copied and pasted, generally without changing the description at the top (which included filename and purpose)

So yes, while I know my code certainly has its own problems, I am 100% sure that my code is more readable, more maintainable, and more correct than the previous guy's. This is not arrogance on my part, this is a solid knowledge of good programming practice and the ability to see systemic disregard for them.

On the topic of TFA, I have actually introduced separate development and release branches in source control, forced the use of an auditable/reversible process to deploy code, and am working on retiring a lot of legacy crap in favour of a third-party MVC framework. So it can be done, if your managers are open minded and you can make a decent business case for doing so.

Re:Something to note about other people's opinions

[mini me]

Also, humans tend to read left-to-right, top-to-bottom. Any worthwhile program is filled with loops, branches, conditionals, calls, recursion, etc.

You're not executing the code. It's still read left-to-right, top-to-bottom.

It's not restating, it's clarifying what the code does

But I'm saying that well written code does not need clarification. When it's well written there's nothing more that can be said in any other language that hasn't already been said directly in the code. I'll admit there are border cases where it's almost impossible to write code that is abundantly clear and under those circumstances comments are a good idea, but those should be few and far between.

Re:Something to note about other people's opinions

[Chatsubo]

Couldn't have said it better. It's always hard to convey the whole story behind a slashdot post and invariably someone points out an omission. I have been lucky to have worked with some really talented people. I am not talking about all cases here.

I believe you are a bit wrong though. You don't ALWAYS tell your managers the code is bad. Sometimes what you inherit is a lot better than what you could have done yourself. If you do always tell your superiors the code is fucked, you probably don't have a clue, or you have really bad predecessors.

Re:Something to note about other people's opinions

[Tesen]

Nope, it wasn't Acxiom, I hear a story here do tell :)

Re:Something to note about other people's opinions

[CmdrGravy]

I am beginning to transition over to OO at the moment, AlmostEverythingObject is almost complete now, it certainly does everything the old functions used to do which I think is what the polymorphic bit is all about and I think I've been quite clever to get it all into just the one object.

Re:Something to note about other people's opinions

[Anonymous Coward]

yes my team have enough time, the key is good project management, if you show clearly that for function X you need specification A, B and C provided by the client, they will spend months in meetings while you develop the application with good methodologies (we use SCRUM), there are a lot of tricks to get more time and not look bad, we show ourselves as professionals, if they say "i need this for yesterday" we simply say it's impossible, show the current work schedule and maybe drop characteristics and include the new one for the next iteration.

Re:Something to note about other people's opinions

[nojomofo]

And what you don't understand is that it's probably the environment that produced code of that quality. Maybe the app was supposed to be a proof-of-concept that management decided to put into production as soon as it was finished. You will soon understand how the company works, and the code that you produce will be no better.

Re:Something to note about other people's opinions

[SilentBob0727]

You're not executing the code. It's still read left-to-right, top-to-bottom. Hell, that can be even more confusing than reading the code the way a computer would.

But I'm saying that well written code does not need clarification. When it's well written there's nothing more that can be said in any other language that hasn't already been said directly in the code. I disagree. Languages differ in their expressiveness, and sometimes human language can be used to succinctly clarify what may take 200 lines of disjoint, complex code to specify in a computer language.

Re:Something to note about other people's opinions

[Tesen]

Do you tell management what you had found? Did you give the previous coder credit for their code being okay? I hope you did, not doing so just incase we piss off management is why clueless management types remain clueless.

My last boss used to question everything I did (she was not a programmer... NOT even close). One day in a meeting I had enough, she was feeling around for me to say something she could embarass me with, I got so annoyed I leaned back and basically said: Well there is one problem you could help me with . Her boss was in the room too :-) Her response: "Lets talk about this offline" (I didn't realize we were online in this physical meeting lol :P).

I said, "okay - but we'll need to set aside about 60 minutes to go over this issue." her boss ended up wanting to be there, lol. The meeting was so funny, I spent most of the time going, "Ummm no, the process does not work like that." or, "That is not how our accounting department handles that." - or having to explain basic programming concepts to her. Her boss was an old mainframe programmer, so he was able to chime in on some quirks I had noted on the big iron side of things. I ended the meeting thanking him for his input, shaking his hand. On my way out, I heard the comment from him: "Wow, a very impressive young man." I was able to also push some credit on to another fellow programmer who had tackled some other issues that I had to resolve in this project (and done a great job!) that she was also targetting. Sorry about being generic about this, but I am still under an NDA so can't be to specific on what I was doing :(

The way I interview is pretty much: I am an !PC guy, I am going to say things that probably should not leave my mouth (not sexist nor racial shit, just harsh comments when ppl are pushing at me). I tell my potential managers, "You embarass me, I am going to make you look like a fucking idiot and believe me, I know how to play the game... so lets agree not to play this game and just stick to work?" My last boss just did not get it, she is the only one that ever fucked with me and kept fucking with me even after I had shown her to be an idiot publically and that I could best her with very little effort.

I actually think she hated programmers or ppl that could do things should could not, we were the only two programmers on her team - the rest were desktop and server admins.

Tes

Re:Something to note about other people's opinions

[Chatsubo]

I've been around this company for going on 3 years and am a senior dev.

I was here when the projects started and ended. When some of the people joined and left, I know the project histories well.

Re:Something to note about other people's opinions

[TigerNut]

When software or firmware is a major component of your commercial output, then it is important enough that it should get as much up-front design, in-process review and documentation as your hardware.

Doing good software design up-front saves a huge amount of time in writing and debugging. If you're doing an OO project of any significant complexity and you get your class definitions messed up, then the code implementation is going to suck, both in performance and in maintainability.

It doesn't only apply to big projects. My code is aimed at 1k or 2k FLASH targets... if you don't design it right up front, then it's not going to fit. When you're coding for something that's going to get masked into ROM, you want to be able to show that every line of code has been tested and that there are no degenerate situations. Add to that a realtime environment where you don't know when certain interrupts are going to happen in relation to each other, and proper design becomes the difference between something that works all the time, and something that is dependent on all kinds of seemingly unrelated occurrences.

Re:Something to note about other people's opinions

[Anonymous Coward]

But I'm saying that well written code does not need clarification.

Here's some well-written code:

                int nIMin = m_nIMax;
                int nIMax = m_nIMin;
                int nJMin = m_nJMax;
                int nJMax = m_nJMin;


So is it a bug? I can hear you protest now that you'd need to see it in context to know. But if I add a single short comment:


                int nIMin = m_nIMax; // initialize to opposite ends of range
                int nIMax = m_nIMin;
                int nJMin = m_nJMax;
                int nJMax = m_nJMin;


you know that my intent was to initialize max with min and min with max.

There is no way to express this in the code itself, and this kind of situation crops up all the time in well-written code of even moderate complexity. People with limited imaginations, who lack the capacity to see that their code could be read in many different ways, are generally unable to grasp this point, even when presented with multiple examples. Sad, really.

Re:Something to note about other people's opinions

[ncttrnl]

Wait... where did the other 8 programmers come from?

Re:Something to note about other people's opinions

[Brad Eleven]

My experience in inheriting others' code is that I've found the "why" to be missing. I've seen a wide range of comments, from 10K lines of C with exactly two comments ("this part is tricky" and "just in case") to a current project with 25K lines of KSH with a comment-to-code ratio approaching 3-to-1.

I can read the code. I can figure out what it's doing. What I want to know is the reason behind, say, maintaining a counter in a file between runs in order to start over next time in the midst of a long list of filenames. It's obvious that the entire list doesn't need to be reprocessed every time, but why stop without processing all of them?

Ideally, the code itself would contain such rationale as an adjunct to documentation describing how the modules, scripts, etc. all fit together to accomplish some goal. That's what I strive to leave behind--either for someone else, or for myself when/if I encounter my code again years later. I've done this about a dozen times so far, and I usually laugh at what I was thinking "back then." Even so, it's readily apparent what I was trying to accomplish, so that I can either tune it up, fix it, or adapt it to a situation that has changed.

The most hilarious code I've ever worked on was hand-optimised C, replete with explanations about why the arrayname + offset notation was so much faster than the arrayname[offset] notation. The fellow seemed to have been so proud of himself for that style that he forgot to check the logic. Most, if not all of the comments came across as bragging about how good the code was, sprinkled liberally with the repeated declaration, "CODE IS MORE EFFICIENT!!!"

The only other comments I really appreciate are those that explain something that might look weird to someone else. I don't mind extra comments so much; they can be grepped out like so much beer foam.

Re:Something to note about other people's opinions

[Chatsubo]

Do you tell management what you had found? Did you give the previous coder credit for their code being okay? I hope you did,

Hell yes.

Re:Something to note about other people's opinions

[korbin_dallas]

Aha, you are SO WRONG!

Q: How many developers does it take to change a lightbulb?

A: NONE. Thats a HARDWARE problem!

Re:Something to note about other people's opinions

[cayenne8]

"Maybe the app was supposed to be a proof-of-concept that management decided to put into production as soon as it was finished."

Wait...are you telling me there is another way??

Next thing you're gonna tell me, is that you don't naturally turn your dev/testing server into production when it is ready to 'go production'....geez.

:-D

Re:Something to note about other people's opinions

[dubl-u]

I think we agree pretty much completely on the spirit of things, and were we coding together, I'm sure we'd get along well. However, I think you got the bit about agile teams wrong.

I've met people of the agile variety who insist that well-written code needs no documentation: that if you carve your code up into small, tight, appropriately named classes and methods it becomes obvious what your code does and your code becomes "self-documenting", [...] it's still a challenge to see the forest for the trees [...] it also means that after several refactors you end up with a whole lot of miniature orphaned functions littering up your code that are never called and that do nothing but that everyone's afraid of deleting)

I'm not sure if you're dealing with idiots who are skipping practices or if you just missed the bigger picture, but either way let me explain how that approach can work very well.

For an agile team coding like that, I'd expect them to be doing test-driven development, working in a team room, doing pair programming, and swapping pairs every few hours.

In those conditions, the bigger picture lives in everybody's heads. You don't write it down because it would be pure waste. The time to document it is when team continuity might be broken. Like when you put a project aside for a while, transfer it to another team, or publish an API. Then you schedule the writing of documentation in the queue with all the other work. That should certainly include a big-picture explanation of the system.

If you've got good unit test coverage, nobody should be afraid of deleting anything. If the tests fail, you just hit undo. And if you've got good acceptance test coverage, most languages have tools that will let you check for unexecuted code. When I'm working in Java, I use IntelliJ's IDEA, which automatically highlights unreachable or unreached code, which I love.

Those tests also shouldn't be mere tests. They should be an explanation of what something is for, built around examples that computers can verify. For the developer side, check out the various Behavior-Driven Development frameworks that have appeared in the last couple of years. For the acceptance tests, see FIT, FITnesse, and other tools that are focused not just on testing but on explaining the product.

The reason Agile people lean away from documentation by default is that documentation is by definition redundant. It's extra work to write, it adds a tax on changing the thing it documents, and it risks drifting out of date. Instead put a lot of effort into making the primary artifacts communicate well (via clear code; great names for variables, methods, and classes; well organized file layouts; clean system architectures; readable tests; and everything else that makes up beautiful code). Every time I get the urge to document something, I first try to make it clearer, so the documentation isn't necessary. When I can't, I document.

Re:Something to note about other people's opinions

[SilentBob0727]

I'm sure the staunch agile supporter would posit that that is NOT well-written code, since it needs a comment. Of course, I would challenge them to come up with a "well-written" alternative.

Re:Something to note about other people's opinions

[Greyfox]

Perhaps I didn't phrase it quite correctly; a single programmer doesn't ALWAYS tell management code is bad, but collectively and statistically programmers as a group do. If someone manages a project that has programmers, he is going to have heard that the code base sucks and it needs to be rewritten and he's going to be suspicious if someone comes and tells him that. If he's not and he happily agrees to it he's going to get burned. Badly burned. And then next time he'll be suspicious when someone comes and tells him that.

Somewhere is a happy land where code is clean and well commented, the requirements were always good and well documented and everyone had a good understanding of the business logic before they started programming. And in that place they probably had some new hire fresh out of college come in and tell them their code base and design sucks. And if it's REALLY programmer Shangri-la, they had the wisdom to fire that person on the spot.

Re:Something to note about other people's opinions

[Traa]

I agree with most all of your stuff, but boy if those are your pet peeves about other people's code (colleagues?) then you got it good mate!

How about

• large macro's
  
• large blocks of duplicated code
  
• use of non-standard libraries
  
• int d,i,j,q,dd,ddd;
  
• #if 0
  

*sigh*

Re:Something to note about other people's opinions

[Nazlfrag]

Oui, you are right, but alas few coders ever try to make legible code. It's very odd I know, but hey it takes a certain insanity to enter the field in the first place, non? There will come a day when the language is not a barrier, but until then I'd recommend the C++ frequently questioned answers.

Re:Something to note about other people's opinions

[kscguru]

Because it *can* cause a circular include dependency which is extremely difficult to detect. FooClass instantiates BarClass instantiates FooClass ... kaboom. And it really does cause a large increase in preprocessing times to pull in all those headers, even simple files end up 10,000-40,000 lines after preprocessing.

That said, I and my coworkers use includes in headers all the time. (ONLY include a header if you need the full definitions; if it's just a FooClass pointer, forward declarations are far better. And don't be afraid to split a header into "foo.h" (struct definitions" and "foo_types.h" (forward decls, typedefs, enums); most clients of the header only need the latter). Writing good code truly is an art form.

Re:Something to note about other people's opinions

[JUSTONEMORELATTE]

If you want employ in Boulder, drop me a line. We're a small ( 50) person company that thinks like you do. gmail, address is OldSchoolGeek

Re:Something to note about other people's opinions

[Anonymous Coward]

style is one eternal point of contention (except for python programmers, but they're in a straight jacket),

If you think Python programmers don't fight about style, you've never been on a team of Python programmers.

Re:Something to note about other people's opinions

[Anonymous Coward]

All the m_'s and n's make it hard to read, that's for sure.

Hungarian... sucks.

Re:Something to note about other people's opinions

[raddan]

The problem with it is this: coming from C, all of C++'s weirdnesses stood out. A vector? Turns out, that's a template class (and a damn useful one), but I didn't know that at the time. Why do I need the algorithm header? What about cin.eof()? cin/cout objects and their flags are damn weird when you're used to just pulling in data from a keyboard buffer and dealing with errors yourself.

When I first saw this, I think I was literally on the level of "how do I get input from a keyboard in C++?" Answering that question with all the bells and whistles of C++ was not what I was looking for. More cognitive load than I needed. And wrt the data structure in question, anything with the word "stack" in it would have made sense to me. Not an array which then gets reversed. Weird.

Re:Something to note about other people's opinions

[Tim Browse]

Over-commented code (the kind where there's 2-3 lines of comments for every one line of code -- not every closing brace needs a reminder that we're exiting a code block, thanks!) is pretty awful too.

That may be true, but when I think back over my programming career to date, and think about the problems I've had with code, I can assure you that "There were just too many comments!" doesn't come up all that often :-).

Re:Something to note about other people's opinions

[oxygen_deprived]

Umm, not necessarily. There ARE master craftsmen who write flawless (almost) stuff. And I dont believe anyone can be bitchy about such code.We had Mark who wrote ~11K lines of C++. Its been 2 years that he left, and we have found 3-4 bugs in it.There have been umpteen bugs in the upstream callers and the downstream callees, but no, not in Marks code.
There have been times when we needed to extend his module's functionality. He had already thought of it, and extending the functionality was a piece of cake.
He wrote about 4K lines of unit testing code with cppunit.And no, it was not the trivial unit tests that checked if the constructors initialized values properly.
He wrote structured and elegant error handling, and his code failed gracefully at negative test cases.
I can go on and on about Mark...Point is that its possible to write code that everyone knows to be non sucker

Re:Something to note about other people's opinions

[Anonymous Coward]

Climate modelling: We recently integrated several models for 10 months on an NEC SX-6. When running code like this you do everything you can think of to make it go as quickly and smoothly as possible. Vectorisation, profiling, loop unrolling and memory access optimisation etc. etc. etc. You look at every operation that is in a loop and think about ways to take it out of the loop. Sometimes these operations take code that made good sense from a sensible algorithmic point of view and rearrange it into something that when examined cold is difficult to follow. If it runs faster though we go with it. And all in FORTRAN.

Re:Something to note about other people's opinions

[coryking]

I would challenge [the staunch agile supporter] to come up with a "well-written" alternative And your code comments will tell them that you tried to create a well written alternative but it didn't pan out because [insert comment here].

Besides making up for language deficiencies, most comments should be exactly "this looks bad, but it is the right solution because [insert reason]" or "this code sucks, but [insert reason]". Good comments aren't English translations of the code, they provide the "what I was smoking when I wrote this". Bad comments are "initialize counting variable".

I should also add that good comments should be written for everything publicly exposed. Good implementations of Intellesense will make life easy down the line by sucking up the comments (or xmldoc for visual studio projects and perldoc for perl).

Really, this entire debate is an old news. People should really RTFM :-)

Re:Something to note about other people's opinions

[mini me]

That's not well written code, I'm afraid. I know that we're talking about minimum and maximum values of something. But what?

Now, if your code looked something more like the following, and given within some more context (a well named function for example), it would be quite obvious as to what you're trying to do.

int minimum_age_of_users = maximum_age_of_dogs;

Re:Something to note about other people's opinions

[gosand]

Codes is an expression of the programmer's though process. Everyone thinks in a different way. Invariably the last person's code will seem to suck because you have to think differently to understand it.

Let me clarify that for you.... Codes [sic] is an expression of the programmer's though [sic] process at a specific point in time. It needs to be clear that projects change... requirements changes... focus changes... priorities change. It's hard to go back and re-design something you did yesterday with today's knowledge because the project may not allow it. Usually you just adapt to what is going on today, and move on with what you have. If you are a perfectionist, chances are you'd be a terrible developer because things will never be perfect. There are just too many variables in software development, and if you require that things be perfect, you'll never get anything done.

That is just the reality as I have seen it. Granted, I am not a programmer, but have been in the software industry since 1993. I've been on a lot of projects. For the most part, you have to accept things the way they are at some point, and move on.

Re:Something to note about other people's opinions

[SilentBob0727]

The reason Agile people lean away from documentation by default is that documentation is by definition redundant. And redundancy is a Bad Thing because? Yes, code duplication is undesirable. Clarification where it is needed is not. Structural engineers would tell you redundancy is a very, very Good Thing.

For an agile team coding like that, I'd expect them to be doing test-driven development, working in a team room, doing pair programming, and swapping pairs every few hours. And scrumming twice a day? Just messing with you. You seem to be describing an XP environment... XP is known to be an unstable methodology, both in theory and practice. Heck, the flagship XP project at Daimler Chrysler floundered until the day it was decommissioned, even with the big XP cheeses at the helm. Change management software where everyone is required to read the commit logs seems to work better at fostering a team code environment than pair programming. There is something to be said for an employee having their own space. In my own experience, the only time pair programming has ever worked is in an EXTREMELY small (read: three people) team. It just doesn't seem to scale. Usually someone sits back and watches the other one code, going, "huh?" until they either give up and do something else or have to switch.

That said, XP has some good ideas (I test-driven development, refactoring) that when combined with the good ideas of the more traditional methodologies (story cards be damned; formal initial design and modeling are important!) create a more flexible development environment.

Every time I get the urge to document something, I first try to make it clearer, so the documentation isn't necessary. When I can't, I document. I would agree with you. Documentation is not a substitute for poorly written code.

To put it more succinctly: Quality comments enhance the readability of quality code. In other words, the art of comment writing is just as important as the art of code writing: there are good comments and there are bad comments. A few well-designed comments can go a long way towards elucidating a block of tricky code.

If you've got good unit test coverage, nobody should be afraid of deleting anything. If the tests fail, you just hit undo. Except when you have a function that's not called anywhere except from its unit test... then if you delete the function the unit test fails! You have to delete the test AND the function and then suddenly you have the same situation of fear of removing two things instead of one.

Re:Something to note about other people's opinions

[Tim Browse]

Coding mantra at my university (as in, I heard it from more than a few teachers) is that you should never have your includes in header files.

Gosh, that's incredibly dumb. I've worked on projects with hundreds of header files - I'm supposed to remember which files I need to include first?

Header files should be modular - the best way to do this is to #include the .h file as the first line of the .c/.cpp file - that way if your header file is not modular, your implementation code won't even compile.

Re:Something to note about other people's opinions

[IngramJames]

The agile guys are right. If the code is written well, it will speak for itself. There's no need to
duplicate what the code says in another language (i.e. english).

Some of the time, that is correct. Most of the time, it isn't. But that's just in my field (financial software). There are two languages in use in the software I write and maintain: "code", and "business". It is vital, in my area, that code is commented well, to explain the business reasons behind the code. Small loops sometimes speak for themselves and don't need commenting. For example, a method called "getAllCashSecuritiesForAccount", if it contains only a simple loop, doesn't need commenting.

But because developers come in who don't have a financial background, and don't know their way around the system, comments in the code are essential. It helps them understand both the code they are looking at, and the business flow.

But the main reason for having clear, concise comments in the code is so that you don't have to read the code. For example (apologies for the VB):

'get the securities in the current scope
avItems = dctSecurities.Items
for nCtr = 0 to dctAllSecurities.Count-1
    Set oSecurity = avItems(nCtr)
    If oSecurity.CurrentScope = enScope Then
          colScopeSecurities.Add oSecurity
    End If
Next nCtr

' Apply the change to each security in turn - if they have the relevant settlement currency
dTotal = 0
For each oSecurity in colSecurities
    If oSecurity.SettlementCCy = sCCy Then
        oSecurity.MakeAChange dNewValue
        dTotal = dTotal + oSecurity.MarketValue
    End If
Next oSecurity

' Handle case of account going short
If dTotal < 0 then
      oAccount.HandleShortChange
End If

The above comments are all aligned. They appear in the IDE in a different colour. They are written in plain English. They are clear and concise. If I am looking for a bug which involves the total value which has changed being wrong, then from scanning 3 lines, written in plain English, it is fairly clear where I should start my search. Yes, given a few more seconds, I can read through the whole code, and see what is being done. But it's quicker and easier to read 3 lines of English than 15-odd lines of code, which aren't aligned.

In fact, possibly the most useful aspect of comments like the above are to eliminate all the code you don't need to read.

You could argue, of course, that the above could be broken down into 3 seperate methods, all clearly named. But I think that's overkill. This is a simple method, doing three simple things. I ought to be able to read it all the way through without having to flip between three different methods, which exist only to save the developer taking the time to type some clear comments.

Lastly: yes, I am aware that the above code performs two seperate iterations of the same objects, and is terribly inefficient; it is for illustrative purposes only, and on no account should be treated with any seriousness :)

Re:Something to note about other people's opinions

[Tacvek]

About this one:

Header files you can't #include without getting errors because you didn't #include something it requires (but stupidly doesn't #include itself) Coding mantra at my university (as in, I heard it from more than a few teachers) is that you should never have your includes in header files.
Of course this always sounded strange to me because then you have to always remember what includes are required for that particular header. I think it had something to do with avoiding multiple header declarations, but I though that's what the #ifndef XXX_H #define XXX_H technique was for.

So what I'm asking is: why have I always heard that #including in your headers is a big no-no?

Well there is also the concern that the header files should avoid pulling in other headers when possible, because that pollutes the user's name-space. Instead, it is theoretically cleaner to use forward declarations of structs, and using a function prototype if you only need one function from a large header.

That said, it is still very common to include header files in other headers. There are various reasons for this.

In the end though, it is basically a stylistic choice.

Re:Something to note about other people's opinions

[Anonymous Coward]

commented telling them precisely what it does, so "int i = a + 2;" has to have a comment above it saying "// create a signed 32-bit integer variable, i, and assign it two more than the value of a".

That's a problem with C/C++/Java, though: that comment doesn't actually describe what it does! It really means (on your 32-bit system) "create a 32-bit integer variable, and assign to it two more than the value of a, MODULO 2**32".

This is why C is such a hard language for writing solid code. Something simple like "ptr->slot;" looks like "dereference ptr, and take the value of slot", but it's really "dereference ptr and take the value of slot, unless ptr is NULL in which case crash". It seems that almost everything in C has unintuitive cases like this.

If you want to write rock-solid C code, you pretty much need to think at this level, so I'm not sure what hard there is in commenting at this level. If you assume that "i = a + 2" means "add 2 to a", you're going to run into trouble sooner or later.

The former is wrong because while it's great that we now know what each little piece of your code does, it's still a challenge to see the forest for the trees in all but the most trivial cases

If you're writing in a low-level language like C that's what you get. If you want to see forests, you need to pick a higher-level language that allows for abstractions beyond just "structs and functions". C is essentially a portable assembly language; it might be OK for implementing a UNIX kernel on bare metal, but it's a lousy application language.

Re:Something to note about other people's opinions

[coryking]

Colour me confused about the Microsoft headers. Is there some docs about this? I'm curious because I am suspecting something is wonky with my include files and maybe you are describing the problem.

Re:Something to note about other people's opinions

[Actually, I do RTFA]

The former is wrong because while it's great that we now know what each little piece of your code does, it's still a challenge to see the forest for the trees in all but the most trivial cases (it also means that after several refactors you end up with a whole lot of miniature orphaned functions littering up your code that are never called and that do nothing but that everyone's afraid of deleting). A good method name doesn't tell the reader why the method is there or what its intended usage is. The latter is wrong as well, because suddenly naturally flowing code is broken up to the point where comments become a distraction and make the code harder to read (incidentally, this is why I started using justified end-of-line comments... it helps with the distraction).

Actually, I think that is the same problem that coveres the "comment every 4 lines" methodology. Where I currently work we have the "comment every 4 lines" thing going (and in comment blocks right justfied to column 81 no less). I've grown accustomed to reading the code, so they are not distracting. However, they are almost always useless:

/* Line of *'s that the lameness filter rejects. */
/* Class declaration ... */
/* Line of *'s that the lameness filter rejects. */

class CClassName

Meanwhile, in a function, code will look like this:

/* Line of *'s that the lameness filter rejects. */
/* Call function X() if i > 0 ... */
/* Line of *'s that the lameness filter rejects. */

if ( i > 0 )
X();

Which is sometimes the only comment given when you need to know that X calls Y which calls Z, and that function Z produces some error unless i > 0, etc.

Re:Something to note about other people's opinions

[Actually, I do RTFA]

The rule where I work is that the naming/commenting conventions must be strictly followed (generally 1/2 of my time). Generally, we have a plan going in, the architecture gets 80% of the way done, and hacks are added to deal with the hardest 20% because of time crunches.

Re:Something to note about other people's opinions

[Anonymous Coward]

Drop the hungarian and make the names more descriptive than I and J and I'll agree it's well written. Right now, it's a god awful unreadable mess, and even your comment doesn't change that.

Re:Something to note about other people's opinions

[Actually, I do RTFA]

Don't forget, you should also store all your variables in an array so they are easy to access ( prefereably global if you have 2 or more functions in your program). That way, you can cut down on the number of switch statements (which break the cashe leading to slower runtime). For instance, instead of switch (arg1) { case 0: a = b + c; break; case 1: b = a + c; break; } you can just use var[arg1] = var[abs(arg1 - 1)] + var[2]; etc.

Re:Something to note about other people's opinions

[asdfghjklqwertyuiop]

style is one eternal point of contention (except for python programmers, but they're in a straight jacket)

Well if your "style" is such that you randomly mix tabs and spaces for indentation in the same code then I can see why you would feel that way.

Re:Something to note about other people's opinions

[Anonymous Coward]

Now you're upset and become very vocal about the problems you now have to deal with.
 
... at which point management labels you as "negative" and uses that label as an excuse to ignore your complaints. After all, the previous programmer didn't see any problems, so obviously you have a bad attitude and complain for no real reason.

Re:Something to note about other people's opinions

[Like2Byte]

I often find passing the function name itself as a parameter helps with loop re-use.
That way you only need to create a single do loop and allow your cx(...) sub (result passed back in the 14th argument unless the 3rd is "E" or above in which case its pushed onto the reference you passed as arg[19 + val(arg4)].

Oh, shit! I understood that!

Re:Something to note about other people's opinions

[TemporalBeing]

Colour me confused about the Microsoft headers. Is there some docs about this? I'm curious because I am suspecting something is wonky with my include files and maybe you are describing the problem.

If you are getting it to compile, then you are past the issue. Otherwise, you can simply include Windows.h, or you can be more minimalist (like I like to be), and figure out the individual files to include, which will actually be better for your program. If I remember correctly, you have to start with WTypes.h, which is the basic Windows types (HANDLE, etc.). It's a pain to figure out but works wonderfully once you've done it. It also requires a bit of research whenever you add a new Microsoft header/API/data type/etc. It's been a while since I've done it, and I don't have a project I can pull from readily available to give you better info.

Re:Something to note about other people's opinions

[Tacvek]

Two points...

Don't forget about header include guarding - as mentioned by this comment, for example. One of the reasons I really hate using Microsoft's headers - they don't do include guards so the order of the includes matters; they use the #pragma once guard, which is not really a guard as you then have to get the order right, and God help you if you have to include your header before another header that ends up creating a circular loop due to the #pragma once guards.

Lack of structure tags, preventing forward declaration. Don't do typedef struct { ... } foo_t; do struct foo_t { }; and a typedef if necessary.

Well...except that when working with Strict C and a compiler such as Microsoft's VS 2005 C compiler, you have to typedef the struct. Annoying but required or else you get all kinds of errors. Been there. Done that. And technically for Strict C, you should be. In C++, however, you are right, but why break the backwards compatibility?

Also, don't forget lack of comments in general either.

Strict C? do you perhaps mean ISO C? Offically the following code is not valid: "struct foot_t{...}; /* other stuff */ foo_t myfoo;" but that is because the valid code is "struct foo_t{...}; /* other stuff */ struct foo_t myfoo;". However, because many people do not like the requirement to include the struct keyword all the time, they simply typedef the struct, often times never give the struct a name, resulting in an anonymous struct.

The best solution though is to go "struct foo_t {...} foo_t;". That allows "foo_t myfoo" to work, but "struct foo_t myfoo" still works fine too. Further should still be possible to forward declare this struct. Please note that this solution is valid C and C++. One word of warning though: do not do a "typedef struct foo_t foo_t;" after the forward declaration. That would work, except that the real declaration of the struct includes the same typedef, and while C++ allows duplicate typedefs, C does not.

Re:Something to note about other people's opinions

[ILongForDarkness]

Wouldn't it be nice if there was an IDE that would allow you to turn on and off comments? Sort of like VS's regions. It would be nice if you had options like, no comments, all comments, only header comments, etc. I agree sometimes you need a lot of comments because the code is doing something really isoteric, and sometimes you want the comments out of the way so you can fit the block on your screen rather than having to remember where you are in the code.

Yet another interesting feature I'd like in an IDE. Something similar to Excel's freeze panes but dynamic. So it fallows the start of the block, so at the top of the screen you'll have:

if (blah == run_some_crazy_spagetti) {

It would make my life so much easier. The closest think I've seen is emacs status bar that will show } // if (blah). I think it makes more sense for the user to look in the intuitive direction (up) for the help on what block they are in not, up and if they don't see it then down.

Re:Something to note about other people's opinions

[TheRealBurKaZoiD]

I came in here to say something similar, and I find the first post has just about said it all. I completely concur with the parent, and only add my own personal view on the concept using an example from my job.

A hire of less than two years was recently asked to resign, so he's gone now. He is 23, with about 4 years of professional programming experience, and has a voracious appetite for technology. He had complete ownership of his first project here, and boy howdy did he knock a homerun with it. Great developer, imaginative, saw the benefits of standardization, and code re-use, and so on. In spite of the fact he is no longer here, I believe he has a very bright future, and I expect to hear big things from him in the future. Why was he to asked to leave? It's complicated, and there is enough blame to go around for all, but basically he would not follow instructions. Here's the scenario:

His boss, project manager A, announces what a homerun he hit. Everyone is thrilled. Project manager B says, I have a new project, much larger, do you think he can handle this project, and can I borrow him for it? Project manager A says sure, and suddenly he's technical lead on a new project. In the end, he couldn't handle the complexity of the project. It's in maintenance constantly for bug fixes, etc, and the powers that be are considering scrapping it and starting over, and tentatively I may be helming it (which doesn't bother me). He basically refused to work on what he was supposed to work on as directed, and chose to work on what he deemed more important. He was written up three times, at which point he was told "resign, or be fired." He elected to resign.

Back to the main point: These junior developers don't just talk bad about someone else's code, they downright refuse to work with it. They don't want to pore over thousands of lines of code to figure out how something works, simply because they didn't write it. They talk about "old school" and "old technology" and "old ways of programming that are no longer relevant". I've got news for you kids, in the strictest business sense, if it works and does what it is supposed to do, then it's not old, stupid, or irrelevant. Unless there is money in re-writing the system, it's just not going to happen.

Further, these junior programmers don't want to admit that they are exactly that: junior programmers. Four or five years developing do not a senior programmer make. There is a business side to the equation, a bigger picture, or why certain decisions are made on an application, and junior programmers lack not only the foresight to anticipate them, but the ability to understand them. There are always exceptions, but my point is many of these junior developers are only hobbyists in disguise. Eventually, if they don't survive, they will move on to a different career in something else, and continue their hobby on the side.

I think I saw someone else on here once say something along the lines of "It's a job, not a hobby. When the powers that be tell you that they want X, you give them X. We serve the customers needs, not our own whims." Truer words were never spoken.

You can knock someone else's code all you want, but more often than not it was written a certain way for a reason. Perhaps it was done out of ignorance, but there is always a method to the madness. I'm maintaining an application now that is old, implemented in many ways that might be considered irrelevant, and the database is de-normalized beyond belief, with the business logic and database constraints intermingled with the application code. Guess what? I don't like it, but I'm also not about to re-write this. It is a bear to maintain, true, but it also WORKS, and the customer is kitten-shitting happy with it.

Finally, my way is no better than anyone else's; programming is incredibly subjective. I've learned more lessons by reading someone else's code.

Re:Something to note about other people's opinions

[TemporalBeing]

Strict C? do you perhaps mean ISO C? Offically the following code is not valid: "struct foot_t{...}; /* other stuff */ foo_t myfoo;" but that is because the valid code is "struct foo_t{...}; /* other stuff */ struct foo_t myfoo;". However, because many people do not like the requirement to include the struct keyword all the time, they simply typedef the struct, often times never give the struct a name, resulting in an anonymous struct.

As I said, with compilers such as Microsoft VS 2005 C compiler, that does not necessarily work very well. It wants the typedef there even for the initial struct declaration:

typedef struct foot {...};

The best solution though is to go "struct foo_t {...} foo_t;". That allows "foo_t myfoo" to work, but "struct foo_t myfoo" still works fine too. Further should still be possible to forward declare this struct. Please note that this solution is valid C and C++. One word of warning though: do not do a "typedef struct foo_t foo_t;" after the forward declaration. That would work, except that the real declaration of the struct includes the same typedef, and while C++ allows duplicate typedefs, C does not.

I am fully aware of the practice of typedef'ing shortcut names. I am still talking about the original struct declaration. I typically don't like mixing the two for clarity purposes.

Re:Something to note about other people's opinions

[AmaDaden]

I am currently working on code that was written in just that environment. It's a mess. All the people who would know how the code works left because they just could not take it anymore. The code is also very buggy and tends to have massive issues all the time. Every few weeks there is a new crisis. The problem with this style is not how the code is now but how the code will be in 3 years. Even if you wrote it you are not likely to remember every part of it after that amount of time. And comments? It's rare that you can find one. When you do it's always from the same few people. You can actually tell who wrote something just on the formating alone. It gives you an idea of how painful something will be ahead of time. If we did not recently get a new boss who knows what hes doing there would likely have been no chance to recover. "Get it out the door yesterday" means your code will crumble tomorrow.

Re:Something to note about other people's opinions

[magical_mystery_meat]

The no-comments maxim of Agile is, frankly, horseshit. Kent Beck came up with it to sell books to people who don't like writing in English. It's nothing but a rationalization for egomaniacs who think they are incapable of writing bad code.

Do you have a cast-iron photographic memory that can always recall what you were thinking at any given moment, six months later? I know I don't. But most programmers think they're infallible and that their code is perfect. They forget that someday someone else is going to have to work on this stuff, and what makes sense to you will likely be complete gibberish to everyone else.

I've seen the long-term effects of this philosophy and it's not pretty. I recently worked in a mature (4+ years) codebase that had been Agile from the start. It was a horrible, convoluted morass of spaghetti, mixing poorly designed classes and refactored-to-metrics code that used 10 methods and 5 classes to do what one sanely designed method would do. There were massive bugs that nobody could find, the code was inefficient, it took a good six months to get the best people in town trained well enough to work on it (and this place hired all contractors so they were writing their code as flashy as possible to show off just in case the other guys on their team happened to interview them for their next assignment).

I won't consider many programming practices to be completely invalid, but refusing to comment is one of them, and I will not work in such an environment again. It is a sign of stubbornness and hubris and neither of those are agile states of mind.

Re:Something to note about other people's opinions

[Beardo the Bearded]

I once wrote a bit of code that was about 15 lines.

With comments, it was about 150 lines.

It was a reasonably tricky set of decoding code that did a lot of fancy things to get the data out of a packet for a specialized application. It worked quite well, with corruption of about 20% still being recoverable into the original data.

Anyway, nothing about the encoder was even remotely obvious. I wanted to make damned sure that whoever had to maintain that code had at least a reasonable clue as to what was going on without having to draw out charts and wonder why the indexes used were flipping at certain points. It wasn't comments like "this is an integer." "Now the integer increases". It was more like: "If the accumulated error goes above the threshold indicated, then we have to move back at least one step to find a different pathway. Since we know that the first pathway was not a match, then we increment the error threshold, increment the index, and *decrement* the position in the message." (I can't remember exactly, it's been a year since I wrote that, I no longer work there, and there's an NDA anyway.)

Another piece of code I wrote stripped the GPS data from a GPS module's RS-232 output. It was trivial to write the code, since it was an iterative loop. However, comments for each line made it impossible to get lost in the series of 15 nested loops and in the placement of commas and other fields. It was really handy to see at a glance exactly which lines were used to skip to any given field.

(Special thanks to the lameness filter for not letting me post it quite right!)

At this point, get the GPS longitude minutes:
$GPGGA,180432.00,4027.027912,N,08704.857070, W
                                  ^^
 
GPS.longitude_min = get_number
GPS.longitude_min << 4
GPS.longitude_min |= get_number
 
Skip the period:
$GPGGA,180432.00,4027.027912,N,08704.857070, W
                                    ^
skip_period;

Any coding practice has to be flexible enough to allow you to make your point. If you're not commenting because you think the code is obvious, then maybe you haven't coded real stuff, or you haven't coded really tricky stuff. Maybe I write my code with a little bit of overkill in the comments, but at least I know that years from now, anyone can take a look and know exactly what I was thinking and know how to update the code.

My code's been reviewed by an independent auditor as "better than most".

Re:Something to note about other people's opinions

[dubl-u]

And redundancy is a Bad Thing because?

It costs more. And here I mean expressive duplication. It's bad for exactly the same reason that copy-paste coding is bad. System redundancy is fine, but you can do that without expressive duplication.

You seem to be describing an XP environment... XP is known to be an unstable methodology, both in theory and practice.

I don't think of what I'm doing as XP exactly, but that's close enough. Still, it's working well for me and my teams. Come to Agile 2008 and you'll find plenty of other people that the practices are working well for.

And by "working well" I mainly mean happy staff, happy managers, on-time delivery, and unbelievably low bug rates. One project we did 6 years ago has been running with no downtime since then, and somebody just found the third bug in production. Recent projects have also been below one bug per developer-month, and often well below. My view: if you make so many bugs you need a database to track them, you're doing something wrong.

Usually someone sits back and watches the other one code, going, "huh?" until they either give up and do something else or have to switch.

That's not pair programming, then. Control should change hands every 5-15 minutes. Both people should have equal access to keyboard, mouse, and screen. Both people should feel engaged. When you ask them the next day, "Who wrote this method?" the answer should be, "We did."

(story cards be damned; formal initial design and modeling are important!)

Story cards work fine for me with collocated teams. That doesn't mean I don't do initial design. I just don't hold up the show for it, or take my initial designs very seriously. The more information you have to feed your designs, the better they will be. And the beginning of the project is when you have the least information. Therefore, all design decisions should be made at the last responsible moment.

One of my teams began doing a web startup in December. They have been doing weekly iterations since then, with releases every couple of days since February. They're now coming up on 2 million visitors a month, and just recently made some of the architectural choices around multi-machine distribution. There was no need to make them sooner, and now they know exactly what they need to do. Easy peasy.

Heck, the flagship XP project at Daimler Chrysler floundered until the day it was decommissioned, even with the big XP cheeses at the helm.

From my understanding, this was a political and business issue, not one with the team's output. They made a payroll system that worked. Regardless, we have learned a lot in the last decade about how to make agile methods work, so judging current efforts by ancient history seems a little unfair.

Except when you have a function that's not called anywhere except from its unit test... then if you delete the function the unit test fails! You have to delete the test AND the function and then suddenly you have the same situation of fear of removing two things instead of one.

Tests are executable requirements. You should be careful when changing requirements. Fear seems excessive, though.

If it's only a unit test that fails, then it's a software design question. If I was unsure about keeping the method, I'd ask the team. If both acceptance and unit tests fail, then I'd ask the product manager (who is sitting right there) if they still cared about that requirement.

Generally, though, I don't need to ask, because I look at the failing test and say, "Oh, right. That's what this is for."

From what I've seen, fear of changing the code is almost always an indicator that the team doesn't trust the tests. Fix that problem first.

Re:Something to note about other people's opinions

[Anonymous Coward]

I believe its a matter of all interpretation:

Lack of const-correctness. Something like void print_string( char* str ); Huh, does it modify the string? No, then why does it take a pointer to non-const? I don't mess around with C enough but, I'll take a wild guess: SPEED/MEMORY?

Not only does passing a ( 4 bytes, seeing how its stated as "str") quicker, but it doesn't have to:
A) open up memory
B) fill in a value somewhere else in memory
C) clean up the memory

In huge loops this stuff adds up, its all interpretation on how well you want your code to perform in the end though.

Re:Something to note about other people's opinions

[greed]

THAT would be a broken compiler. Not a strict compiler; it is actually non-conforming to the standard if it won't accept:

struct foo { int a; };
int main(int argc,char **argv) {
struct foo bar;
}

A conforming implementation must accept and correctly compile all strictly conforming programs.

Also, use of the '_t' suffix is not a good idea if it is a structure name and not a typedef; so continuing the above:

typedef struct foo foo_t;

(A certain blue three-letter company created a serious problem in a system header by incorrectly leaving the 'typedef' off of one of those. The result was a violation of the ANSI C++ One Definition Rule, and very strange crashes because GNU C++ ties global initialization to the name of the first global definition in a translation unit--and of course, system headers generally come before user code. It was wrong in C, also, because foo_t wasn't a typename, it was a global variable defined in every .o file, but you didn't get the crashes.)

I'm not a fan of Hungarian notation in general, but the '_t for typedef' meme is reasonably well-entrenched, and it does work with both K&R compilers (which have a single namespace for struct, enum, union and typedef) and ANSI/ISO compilers (which have separate namespaces), so that one I'm not complaining about.

Fortunately, I haven't had to deal with K&R C for a few years.

Re:Something to note about other people's opinions

[RSA7474]

Is this why everyone is blown away at the released bits of Microsoft OS code?

Re:Something to note about other people's opinions

[jamie(really)]

LOL. As much up-front design as your hardware? Wow. May I suggest that you go and read chapter 11: Evidence, of Craig Larman's Agile & Iterative Development.

Why Still Waterfall Promotion? - There are at least seven reasons why the waterfall continued to be promoted, including lack of awareness of the growing evidence that it was not ideal, its simple definition, and the allure of simple progress tracking (such as "requirements complete").

says you:

Doing good software design up-front saves a huge amount of time in writing and debugging. If you're doing an OO project of any significant complexity and you get your class definitions messed up, then the code implementation is going to suck, both in performance and in maintainability.

In fact all the evidence points to the opposite. Projects implemented with big up front design, requirements analysis, UML diagrams, etc are far more likely to fail than Agile ones - the advantage however is that because they have huge amounts of work done long before you actually learn of the failure you can get another job before the shit hits the fan.

Even the author of the original "Waterfall" publication actually argued in the article that waterfall was bound to fail!

Certainly, if you don't know about Agile, then doing up front design will mean you can spend less time writing and debugging than if you just hacked. But you have discovered a local minimum. When I do Test Driven Development, for example, I hardly ever run the debugger, because the code works.

I would highly recommend TDD for your real time state machines.

Re:Something to note about other people's opinions

[ryanscottjones]

I've met people who won't even look at code unless every single line is commented telling them precisely what it does, so "int i = a + 2;" has to have a comment above it saying "// create a signed 32-bit integer variable, i, and assign it two more than the value of a". This, in fact, is one of my biggest pet peeves. Give that variable a name. Everyone knows it's a 32-bit integer, but they don't know what the hell it is doing in your code. i could be a counter, a page number, an offset... as someone looking at someone else's code, "i" tells me nothing. "a" tells me nothing. And chances are pretty good that six months from now, even the person who wrote it originally won't know what that "i" is for, either without going back through the code and trying to figure it out. Give that variable a name... most of the time that's all you gotta do to make your code 'comment itself.'

Re:Something to note about other people's opinions

[fbjon]

That's not the worst problem with the code, my immediate question was "what is v, and why do we want to put several doubles in it?". It's like reading a suspense thriller, the ending provides the explanation. A single line comment at the start: "//Read in doubles and print in reverse order" would give all the explanation needed for anyone to figure out what happens, even for someone who's never seen C++ before.

Moreover, single-character variables outside the scope of a loop should be banned from the face of the earth. It's all right to use them when coding, but when the coding is done, for god's sake rename then to something sane.

Re:Something to note about other people's opinions

[cyberfunkr]

There are a few times where I've spent a month or so just simulating coding. It usually stems from getting projects like "Your next project will be making a module that will interface with this e-commerce website another team building." End Of Line.

So I spend my days writing notes about probable requirements, designing theoretical databases, creating unknown API standards, and dreaming of writing makeshift documentation.

Now, my marble[1] is in place, and when I get finalized software requirement docs, I can just remove everything that isn't my "elephant". That is until the final docs say that I'm really writing something to convert PriceLine.com into an RSS feed.

I end up with a lot of really clean code that the world will never see.

[1] Old saying, "How do you sculpt an elephant? You take a big block of marble and remove everything that isn't an elephant."

Re:Something to note about other people's opinions

[zgregoryg]

If this line is you, "I am downright embarrassed by the quality of my code. It is buggy, slow, fragile, and a nightmare to maintain," then yes, you should listen to other's opinions about your code. If the above does not describe you and your code works as intended, then consider the opinion of the persons who makes changes. If those changes do not create significant improvements in execution, then consider your lesson learned.

Re:Something to note about other people's opinions

[Anonymous Coward]

Its like a right of passage or something. rite of passage, you mean.

Re:Something to note about other people's opinions

[jafac]

Actually;
I'm working with a guy now, whose legacy C code (dating back to 1992) generally, functions() take a single String parameter, which is actually a long string of concatenated parameters - and inside his function, he'll parse it down to individual operating parameters (and every function does it a little differently). He wasn't really exposed to any formal training as a programmer back when he wrote this stuff, nobody ever told him it was wrong, it's just the way he's always done it, and now, as you can probably imagine, the code is a nightmare to maintain. Whenever something has to be changed; like a parameter added, ALL of these functions (thousands, literally) have to be modified, in order to allow the parsing to work properly.

And where do these concatenated parameter strings come from?

Why - ASCII files, read-in at runtime, of course. And these ASCII files are somehow "not included" when we decide to do a code-freeze before a build. If he decides he needs to change these parameters at any time between the build and completion of the (newly designated) formal test process, then by gosh, he changes them!

Re:Something to note about other people's opinions

[Anonymous Coward]

You forgot one:
* The entire retarded concept of header files. Why the hell must you repeat yourself. It isn't expensive to do 2 passes w/ a parser now!

Re:Something to note about other people's opinions

[nahdude812]

There is too often a difference between what a block of code does and what it is supposed to do. Code comments can indicate the intention of a block of code. This is a big deal, because I see code which passes test cases all the time, but which don't work as intended especially under exception circumstances (what if the arguments were a value other than what was expected).

Plus sometimes you can understand each operation in the code block but not know what it does. Have you ever looked at an MD5 implementation? You need a comment that tells you what it does in general terms even though you know what it does in specific terms.

I believe in making my code self documenting as much as reasonable, but any time I'm not simply reading data and outputting it (or reading data and inputting it), a backup comment describing the purpose both makes it easier to read and to maintain.

Re:Something to note about other people's opinions

[SilentBob0727]

This, in fact, is one of my biggest pet peeves. Give that variable a name. Really not the point of my argument, although I'm sure getting reamed for it ;) It was just an example off the top of my head and it didn't come from a real piece of code, so those variables really didn't mean anything. Had I used metasyntactic names, perhaps this whole thing could have been avoided?

In any case, when you're doing iteration in Ruby, it's fairly common to use single-letter variable names:

User.find(:all).collect{|u| u.id}

It's quite clear from that context that "u" is a user. It doesn't necessarily help to change that "u" to "user".

In the case above, "i", "j", and "k" are common loop indices. Mathematicians make do with single-letter variables all the time (although some are known to be slightly insane). An abbreviated variable name is OK if its context is well-established.

Re:Something to note about other people's opinions

[SilentBob0727]

That's not well written code, I'm afraid. Eye of the beholder, my friend. Within its context it could make perfect sense. I myself hate hungarian notation but I let it slide as a matter of taste. Overly verbose variable and method names don't solve everything.

Let me ask you, what's the best option out of the following three?

1.

// Does something complicated
// NOTE: foo must be greater than zero
private int someComplicatedFunction(double foo) { ... }

2.

private int someComplicatedFunctionOnValuesGreaterThanZero(double foo) { ... }

3. Refactor the code

Re:Something to note about other people's opinions

[SilentBob0727]

C has enough goodies like callback pointers and structs that you can make it behave in a more abstract fashion if you want. You can still achieve encapsulation and polymorphism in C, it's just a little trickier.

But forest-for-trees crops up even in languages like Java and Ruby. You simply can't just take a piece of code, no matter how well-written, read it like a book, and instantly know exactly how it works.

Re:Something to note about other people's opinions

[Anonymous Coward]

> Header files lacking comments about what functions do.
>
The names should be sufficently clear by themselves (most of the time). Comments should not be per function. Ideally, comments are for describing the *design* of your code, not the low-level details !

> Use of non-standard names for types with a fixed number
> of bits, instead of those from stdint.h/inttypes.h.
>
It is often a good thing to *isolate* the names you use in your code from the names of the libs you use, even when these libs are the std ones.

> Lack of const-correctness. [...] Huh, does it
> modify the string? No, then why does it take
> a pointer to non-const?
>
OK for this one... although you seem to consider that its not your job to *read the code* of the function. But of course it is !

> Files indented with two spaces instead of a tab,
> or even just one space.
>
Everybody disagrees about that. E.g., the tabs are mandatory in the Linux kernel, but banned in the Python community. Who should I believe ?

As you said, using automated tools and do not bothering people with such issues seems to be the only sensible approach...

> Unnecessarily space-taking comments about a
> function's visible behavior. Things with lines
> of stars around everything, etc.
>
I agree with this one.

> Fundamentally, things that aren't highly
> modular and can be understood and used
> in isolation. I want to combine modules
> and have a minimum of complexity increase
> due to this combination.
>
In practice, it's often easy for the lower layers of your software, but not for the rest.

Combining modules without having to look nor to change their code is what everybody wants.

The only problem is : writing reuseable code is the hardest of all things in software design.

Thus of course, you can say "I want", take it for granted, and criticize people for not doing it, but in the end of the day, it doesn't make your job easier.

Speaking with the people and turning the design of your software to something explicit that everybody clearly understands *IS* the (only) way to solve such problems.

Re:Something to note about other people's opinions

[Darinbob]

I'm sort of two minds about this.

First, I do take pride in my code. I make sure to put in comments so other people will understand the code (I'm sick of having to debug stuff with poor or no comments). I have had people tell me my code is generally good and that they "trust" it. I try to give readability and maintenance of my code priority. I worry about things like "what if someone will need to add a feature in the future?" or "what if the hardware changes?"

On the other hand, I'm slower at coding this way. My productivity isn't as high as others who have the "check it in early" approach. My definition of "good enough" doesn't always match my superior's. I have big mental hurdles to overcome when I need to just quickly make a change. When I see a bunch of messy code from others I feel an urge to rip stuff out and rewrite in a clean manner and have to restrain myself. I'm a bit resistant to following the team's standards at times if I disagree with them (generics, component models, variable naming). So the perfectionist in me gets in the way a lot.

Re:Something to note about other people's opinions

[Anonymous Coward]

Heh. It looks like you found 12 different ways to say "some fucktard wrote this in C".

I admit, that's a common pet peeve. But isn't it also poor style to use 12 sentences to say what one will do?

Re:Something to note about other people's opinions

[lena_10326]

I've seen that also. I've even done it to others, although I've eased up a bit on that the last few years. Criticizing style is somewhat pointless. For me code quality means readability first, efficiency second. If the style is affecting one's ability to read the code, then one is probably being being too rigid, given average code from an average developer.

The other thing is no one wants to be held accountable for other's mistakes, so it's tempting to register complaints ahead of time so that problems in the future can be blamed on the original author with some credibility. Planting suggestions beforehand seems to lay a path for "See, I told you so" type of discussions.

And lastly, everyone likes to feel special and unique. No likes accepting that we're all replaceable, no matter your IQ, no matter your work history, no matter what marvelous project successes you've had. We all form the "everyone else sucks" attitude in order to portray ourselves better than the rest so we can shield our egos from the difficult reality.

Re:Something to note about other people's opinions

[Anonymous Coward]

The only sure-fire bug is the dead code on lines 2 and 4. The comment means nothing, and an idiot wrote it anyway. The first thing to do is to write a unit test that expects the correct behaviour, whatever that is, and apply to the code. You don't have any bugs if you don't have failing tests for them... you just have an incomplete specification.

Re:Something to note about other people's opinions

[edwdig]

Longer functions should be divided up into "paragraphs" with comments stating what's about to happen and how the current state contributes to the overall goal of the function. If your functions have extremely clean divisions of functionality, consider breaking them up into smaller private functions unless you're concerned with every last ounce of performance and can't afford the 10-20 cpu cycles necessary to do a function call (or declare the methods as inline).

I followed that approach on a game I was working on once. The main processing function had lots of small little sections, things like "loop over objects of type X and update them" followed by "loop over objects of type Y and update them". At first each of the sections was pretty small, so I didn't think it was worth breaking them into separate functions.

Eventually the main processing function grew rather large, so I decided to break the different segments of it into their own functions. Performance actually went up noticeably when I did that. I think the compiler just had an easier time optimizing the smaller blocks of code.

Re:Something to note about other people's opinions

[SilentBob0727]

It's amazing how liberating it can be when we shed our assumptions that compilers behave exactly the way we were taught in CS 101 ;-)

Re:Something to note about other people's opinions

[ryanscottjones]

An abbreviated variable name is OK if its context is well-established.

Oh, we definitely agree on that. And I'm not suggesting that these are things you do. I'm just saying that in my experience it actually has been a real problem with people who don't know when it is appropriate to abbreviate and when it is not. Some people only abbreviate, and if they are no longer in your organization and there is a bug in their code, that can really ruin your day.

Keep in mind, I believe we're talking boring old application code here, not algorithms. I would expect algorithms to use many indexes (your i's and j's and k's), vs. boring old application code which is just performing some step by step routines. Two completely different planes of existence... no one should expect a good algorithm to be readable. In fact, in my experience, the better the algorithm, the less readable it is. :)

Re:Something to note about other people's opinions

[nonsequitor]

do people out there really have TIME for coding methodologies, reviews and the like?

You have to make time for the important stuff, its not finished until all the i's are dotted and the t's are crossed as far as management is concerned. The alternative is much worse, let me describe a typical scenario for you.

Let's say you rush through and get some code that "appears" to work, you tell your boss "Good news, the code works." The next thing you know you need to have it to the customer tomorrow. Turns out your code is a mess, nothing has been thoroughly tested and it breaks when the customer tries it.

Your boss is pretty upset at this point, you've just embarrassed your company in front of a customer. You work with the customer find out how it broke, fix it with a hack, knowing you'll clean it up later and send a new version to the customer. You still haven't fully tested it at this point, but thats okay because they needed this last week.

The software breaks again, the cycle repeats a few more times and now you have something which is stable. You ask your boss for time to clean up the hacks, he says no, I have another project for you. A month later the software breaks again, to fix it you realize you have to rewrite the whole thing because the lack of proper design and hacks layered upon hacks make it necessary to do major rework.

By the end of all this you've lost a customer, they've decided that the price of doing business with you is too great because you're unable to estimate how long and how much a job will really take, and it interferes with their business.

Now consider the alternative, you throw together some code that works and tell your boss "Don't worry, I have some proof of concept code finished and it will take only 3 more weeks to finish this project." You use that code as an example and design, have design reviews, code, have code reviews, and do unit and integration testing. When you deliver it to the customer, it works, is robust, and you have a happy customer.

As a programmer, it is your job to properly manage the expectations of those around you so that plans can be made around your deliveries. If your code always works when delivered, as opposed to almost invariably having easily exposed bugs, you build a reputation for being reliable and having accurate estimations. Sure it takes longer, but a few extra weeks up front can save months of time down the road.

Re:Something to note about other people's opinions

[Darinbob]

Here's some wierd stuff I've come across:

- Header file defining system wide types that includes both
              typedef unsigned long ulong32_t;
              typedef unsigned int uint32_t;
    So many files depended on that that I gave up trying to fix the code after 2 days.
    (The compiler didn't have "stdint.h" when this was first created)

- Apparently someone heard that passing by reference is more efficient than
    passing by value, so I saw a lot of these declarations:
              void somefunction(const char& value);

- Lack of knowledge about what standard functions are available, as in:
              bool compare(const char* a, const char* b)
              {
                    std::string strA = a;
                    std::string strB = b;
                    return (a == b);
              }

- The guy who learned from one of those "Learn C in 10 Days" books who
    didn't know about indexing into "char *" strings and used:
            strncmp(a+i, b+i, 1);
    (He was an old MVS assembler guy, so he probably assumed that these were
    high level macros instead of function calls)

- They guy with typos in his variable names. Instead of changing the name of
    the variable he'd change all the uses of the variable to have the same typo.

- The cut-and-paste indentation style. This guy didn't care much for functions,
    so if he saw a piece of code he wanted to reuse, he'd cut it from one loop and
    paste it into another. Without re-indenting.

- Nested calls of long macros. Ie, macro expands into 10 lines, 5 of which are
    also macros that expand into 10 lines, 5 of which are...

Re:Something to note about other people's opinions

[raddan]

So true.

Re:Something to note about other people's opinions

[Anonymous Coward]

I've never had enough time to ignore most of that stuff.

Re:Something to note about other people's opinions

[gravitypants]

Haha. Eiffel. I had completely forgotten that language existed. Apparently my school used to teach it in its beginner CS classes. I have yet to hear about any actual industry use. All the teachers apparently loved it though. Eh, c'est la vie. I'll just file that next to Prolog programming, how to sew a button, and the $50 off a new Jaguar coupon in the list of things I'll never ever use.

Re:Something to note about other people's opinions

[DragonWriter]

The agile guys are right. If the code is written well, it will speak for itself. There's no need to duplicate what the code says in another language (i.e. english).

Perhaps, but before you start writing code (if you are doing TDD, even before you can write tests), you should and probably do already know what it needs to do, and chances are that knowledge is already written down in your natural language of choice.

And, in any case, even programmers who can write code that works are more likely to be able to write a human-readable explanation that is comprehensible to people who aren't equally-competent programmers in natural language that they are to be able to write self-explanatory code.

Re:Something to note about other people's opinions

[tengu1sd]

Think and spec. Understand the customer's requirements and make sure the customer understands the customer requirements. I was once filler on a project, converting customer data for a product to product upgrade. My group was lightly loaded so I was servicing another group. I spend 6 weeks talking to customer, something the project lead thought was a waste of my time. He metric was "how many lines of code have you produced?" In that time I generated a database (MSAccess) with tables of the old data formats, new data formats and cross references. I also noted custom conversions requirements. The customer got reports of what was going where, what data couldn't be converted at all, and assumptions. I got corrections, updates and revisions to my assumptions. After all this, one morning I wrote a program that generated code out of my database, the main routine to set up i/o to drive the generated code, and about a dozen routines that covered the custom flags. Before lunch time, I'd generated over 18,000 lines of code and had test data available. Because of the close customer contact, there was no conversion cleanup once the live database was in place. My manager, who understood my approach, kept the project lead calmed down.

Re:Something to note about other people's opinions

[Anonymous Coward]

The reason Agile people lean away from documentation by default is that documentation is by definition redundant. It's extra work to write, it adds a tax on changing the thing it documents, and it risks drifting out of date.

Mr dubl-u, Agile folks, it is time to say hello to my little friend...

Re:Something to note about other people's opinions

[famebait]

To the original poster:
The most important part is not in your boss but in you - if you want to be proud of your code, you have to start by taking pride in the readability of you code. Your ambition should not be to write code that is readable, but textbook quality: it should be suitable not just as an example to others, but should itself be instructive to others. Not hat you can always do that, but you should hold it as something you _want_ not something you 'ought to'.

Yes, crunch times and asshole bosses can make it necessaary to cut corners, but make it clear that this way of working insults you (not for aesthetic reasoons, but because it's wasteful ands stupid). But you can get away with a lot of best-practice work if you stay focused and don't start adding stuff you don't need. And it usually takes less than days for tidy code to pay off, so unless someone is peeking over you shoulder, you might not even have to defend it. _Never_ do anything "quick-and-dirty". There will never be an 'afterwards' in which to tidy up. If it's worth doing, it's worth doing properly. What you _can_ (and should) do is "quick-and-_simple_": cut features to the bone until you need them. Don't be tempted to make framework when what you need is a function. But be ready to refactor it out (to the germ of a framework) when a more general version is needed. It sounds like more work, but it usually isn't in reality, and there's less code to debug later, and you won't introduce bugs when one implementation changes and the other does not. This, again, has noticable effect even on the scale of days.

To the parent:
I agree that proper API comments are essntial, but faced between a well-commented but ugly API and a well-designed, well-named and consisten one with only minimal comments, I'm not sure I'd always take the well-documented one. Especially not if the code inside is clean enough to worthy an little look.

But when it comes to commenting internal code, a rally good habit is to rough out the general structure in a coarse pseudocode of TODO comments before coding, and then fill in the blanks, removing the TODO tag but leaving the text as a heading as each block is completed. And adding new todos as you think of stuff as you go along. That way the commenting becomes not a chore but a _really_ useful aid in you work, helping you think clearly and reminding you of context even when littel code is written yet. And of course, when it _saves_ work in stead of adding it, it becomes a lot more likely to get done, too.

This comment style goes very well with another good practice for readable code, that probably has another name but which I call "bailout" logic:
Use guards of various types to throw out pathological or skip-cases as early as possible (throw exceptions, use 'return', 'break', and 'continue') in stead of nesting everything that actually happens deep inside multilevel if/else/switches, or constructing complex or clever (a.k.a. bug-prone) condition statements.

This makes for a nice, 'story-like' read for the 'normal' or most intersting flow. It will often be a good idea to add a brief comment after such a bailout (or the block it is in), stating the precondition that has now been met by virtue of getting here.
Some people oppose this style, since you have exit points all over the place in stead of everything merging at the end. I will gladly trade that for making it _much_ easier to get a clear picture of what kind of state I'm in when I actually reach some interesting code. And you simply have less cases to worry about for most of the code.

Sometimes, if neither 'while', 'for' or 'do-while' _really_ map all that well to your actual loop logic, you can be a lot more by understandable with "while true", and then break or continue explicitly where they fit naturally in the sequence, in stead of forcing it to the start or end (or *shudder*, abusing the increment statement to do actual work)

Re:Something to note about other people's opinions

[famebait]

Not so. I have had to take over several other people's code, and the differnce in quality is huge. OK, so everyone has _something_ that bugs me, but some things are pretty easy to deal with (or quick to change, if you're really anal about style), while others are just plain cargo-cult programming where it is quite clear that even they didn't know why it works, demonstrated by how they've worked around shortcomings in a section of code that has grown too hairy, in stead of just fixing it.

Beware of the guy who delivers at staggering speed the first two weeks. Jeezus, some of the messes I've seen.

Re:Something to note about other people's opinions

[SoulRider]

Opinions are like assholes, everyone has one and most of them stink.

Re:Something to note about other people's opinions

[tilde_e]

How about int nReversedIMin = m_nIMax; for starters? Do you really believe a single line comment that could be 40 lines above the code that uses nIMin is sufficient? Adding the comment there just says "I intentionally made this code confusing. Good luck."

I think if you relax your absolutism a little you can find better solutions.

(BTW, m_ is a very weak convention. 'this' is much more clear and some compilers can enforce that you *must* use it -- Eclipse/Java project settings for example. I've also seen someone prefix every function parameter name with 'arg', what is that about? Talk like a pirate day?)

Re:Something to note about other people's opinions

[Almahtar]

How do they find the time for that? How do you find the time NOT to do that? Following a structured process tends to expediate development a lot.

Re:Something to note about other people's opinions

[Puff_Of_Hot_Air]

I find this attitude disturbing. Where I work, all code is based on coding standards and is peer-reviewed on a daily basis (and I have a high level of respect for the code generated by the people I work with). No one can say your code sucks if they approved it in the first place! In my opinion, if everyone in a company is saying that everyone elses code is rubbish... Maybe the answer is that everyone's code is rubbish.

Re:Something to note about other people's opinions

[Chemisor]

> Here's some well-written code:
> int nIMin = m_nIMax;
> int nIMax = m_nIMin;
> int nJMin = m_nJMax;
> int nJMax = m_nJMin;
> There is no way to express this in the code itself

Oh, really?

typedef pair<int,int> range_t;
range_t nI = m_nI, nJ = m_nJ;

This is far more obvious than your comment solution.

Re:Something to note about other people's opinions

[WinterSolstice]

That's not pair programming, then. Control should change hands every 5-15 minutes. Both people should have equal access to keyboard, mouse, and screen. Both people should feel engaged. When you ask them the next day, "Who wrote this method?" the answer should be, "We did." Sorry, but that would send me right through the door. Enjoy :)

Re:Something to note about other people's opinions

[thejuggler]

This is lifted straight from a section of our code:

//THIS IS A HACK - because the client wanted is this way!

Re:Something to note about other people's opinions

[Anonymous Coward]

Baby Charles Simonyi cries in heaven when he looks down and sees what you've done to Hungarian notation.

Re:Something to note about other people's opinions

[Evil Poot Cat]

This is so, very true. Why think when you can spam? It's much more 'productive' that way.

Re:Something to note about other people's opinions

[JavaRob]

But I'm saying that well written code does not need clarification. When it's well written there's nothing more that can be said in any other language that hasn't already been said directly in the code. I'll admit there are border cases where it's almost impossible to write code that is abundantly clear Have you never been brought on to maintain a large codebase that you didn't write? Even if it's *beautifully* elegant and refactored to a sparkling shine of perfection, you're still going to be lost in large sections of it for a while. There's going to be project-specific terminology decided by the developers in variable & class naming that you'll have to learn, and you simply cannot always glance at a single shard of an enormous project and comprehend where it fits into the whole. Ideally, you're going to have a whole lot of relatively independently functioning little parts, right?

Suppose you have an exception raised in a given class. You know the line number, and you open the class... if it's involved in serving a purpose that's low-level enough, it's going to take you a far more time to figure out what it's for, how it's used, and what role it plays in the project as a whole if you don't have, say, 3 simple lines of plain English in the header comment.

Personally I don't write too many comments in my "normal" code. I write progressively more as the code gets more complicated -- some features are simply too complex to even fit the implementation in my head all at once, so I write a shorthand walk-through of the implementation before I start. When I'm done, sometimes the code has actually boiled down enough that I can chuck that (sometimes I'm not so lucky).

You have to comment implementations that "look wrong" or are counter-intuitive, possibly because of client demands ("the last software package did it that way, so our other systems are designed to correct for it..."). What, are you naming methods calculateScaleWronglyPerClientRequest()?

It can be wise to flag methods (or classes) that will *appear* unused to refactoring analysis, because they're loaded & accessed dynamically.

I could go on.

Re:Something to note about other people's opinions

[SilentBob0727]

except in your hungarian that would be:

range_t rngI = m_rngI, rngJ = m_rngJ;

Of course, not everyone writes in C++...

Re:Something to note about other people's opinions

[Jack9]

I think part of the problem is that programmers lack the courage to just think.

It's more intuitive to find that programmers lack the TIME to just think. Courage has nothing to do with it.
The longer ANY programmer spends on the same code, the better it gets designed (if not written).
Really good programmers criticize themselves as they write and are almost never happy with a refactor.

A second advice would be to keep abstractions as simple as possible.

I'm not sure how that is helpful advice. You can't know how simple you can make something without usage. We come back to spending time reworking something you've already written. Once you see how other people (or just yourself) need to use it in the real world, you know how complex it *NEEDS* to be. Programmers are generally lazy and do not write things more complicated than necessary. When you start out sometimes it can get out of hand, but you come back to reality or dont ever come back. /For who, exactly, was that advice...insightful?

Re:Something to note about other people's opinions

[lucas teh geek]

Unnecessary non-portability. Don't use #include unless #include isn't sufficient.

I dont follow? is there a typo in there somewhere? dont use #include unless it's not enough... huh?

Re:Something to note about other people's opinions

[Gorobei]

Aargh! I've seen this anti-pattern so many times!

1. You have a crappy codebase.
2. New builds therefore exhibit new bugs.
3. So tons of reg tests are done on builds to ensure behaviour didn't change.
4. Then the release cycle goes from hours to days then to months.
5. And the programmers start moving functionality from code to data, cos data is more mutable according to The Rules.
6. And things get even worse cos there's more pointless code in the system.
7. And you add more managers to control the whole process.

Eventually, if you are lucky, senior management sees it has a clusterfuck on its hands, and hires someone to fix it. Sadly, a lot of the time, management hires the wrong person, and the whole thing just dies.

Re:Something to note about other people's opinions

[jamie(really)]

By using m_ you have indicated to us (without comments) that your object stores two ranges. The method in question reverses these two ranges and then does something. I put it to you that either the method in questions will be something like:

void DoSomethingWithReversedRanges()

which makes your comment redundant.

Even better, since your object does something with ranges, your code might be better:

MyObj temp = this.ReversedRanges();
temp.Method();

Again, making your comment redundant.

Re:Something to note about other people's opinions

[botrunner]

Another good is example is the approximate inverse square root algorithm wikipedia link which uses non-obvious aspects of floating point representaion to rapidly calculate 1/sqrt(x). The function is short and simple, but without explanation, how many people would immediately know how it works ?

float invSqrt(float x)
{
float xhalf = 0.5f*x;
int i = *(int *)
i = 0x5f3759df - (i >> 1);
x = *(float *)
x = x * (1.5f - xhalf * x * x);
return x;
}

Re:Something to note about other people's opinions

[bbbb45]

And software developers, who are often not the most mature people in the world, tend to have a habit of thinking that their thought processes are superior, and if they cannot grok yours, then clearly you must be as retarded as the people in marketting and sales (who are, of course, making a lot more than they are). Nerd machismo is the saddest kind, because, unlike other forms of machismo, there isn't the prospect of cred with the ladies.

Re:Something to note about other people's opinions

[Anonymous Coward]

You took a month to do a weeks worth of work?

I'm surprised you didn't get fired

Re:Something to note about other people's opinions

[GermanDZ]

You always can write:

int nILeftBound = m_nIMax;
int nIRightBound = m_nIMin;
int nJMin = m_nJMax;
int nJMax = m_nJMin;

So, probably name the vars better is always cool. Or think about a professor talking about Mr. G and Mr. R in a history class, may be not so clear; much people will prefer Mr. Reagan & Mr. Gorbachev. And remember... not everybody is so clever like you and me.. I learn Basic when I was 10 ys old, at 13 I programed some Assembler (for my ZX Spectrum), later Pascal, C, C++, Visual Basic, Visual C++, Java, CORBA, PHP, .NET and many more.

Re:Something to note about other people's opinions

[Anonymous Coward]

That isn't well written at all. It isn't even correct. By not using a temporary variable, you just set min and max to both be max for I and J. Secondly, the variables are clearly misnamed if it ever makes sense for the "max" to be greater than the "min". There maybe people with limited imaginations but you're demonstrating a different form of limited brain capacity...

Re:Something to note about other people's opinions

[Anonymous Coward]

C has enough goodies like callback pointers and structs that you can make it behave in a more abstract fashion if you want. You can still achieve encapsulation and polymorphism in C, it's just a little trickier.

Sure, but once you've abstracted out enough that you can safely add two integers or look up a slot without everything blowing up, it doesn't look at all like C any more, and the extra layers remove any performance advantage C has, so what's the point? Why not just use a language with support for these things to begin with?

But forest-for-trees crops up even in languages like Java and Ruby. You simply can't just take a piece of code, no matter how well-written, read it like a book, and instantly know exactly how it works.

Of course it happens in Java -- that's basically C with a GC. Ruby is a bit better, and for the most part it's readable, but they still don't have real syntactic abstraction so you end up using object-orientation for a lot of syntactic things as well.

Sure, it's possible to write crap in any language. But can you give an example of an algorithm that can't be expressed clearly in a high-level language? I'd be curious to see it.

Re:Something to note about other people's opinions

[jebblue]

>> And for the love of God, don't comment your private variable accessors The love of our God is not tied to how we do or don't comment our code, please leave his name out of the matter in this context.

Re:Something to note about other people's opinions

[XavidX]

// Comment:The Next Line is a comment to explain this function
// This function will take the user to another page when the user clicks the button
private void btnRedirectClickFunction(params)
{
//This line will redirect the persons to another page. See Previous Comment as to how the user got here
Page.Response.Redirect("someurl")


I dunno about everyone else but I comment code only if it is unclear or I am doing something that requires explaination. Overcommented Code is harder to read. I also comment changes in existing code and why I made the change. }

Re:Something to note about other people's opinions

[MikeFM]

I dunno - I've seen a lot of really bad code. Sure you'll get differences of style but that is certainly not the only issue involved. A lot of programmers suffer from being to lazy, or to busy, to document their code and from the chronic need to make code super tight and hard to grok. As if shaving down names and getting code to run in one line when it should take ten is an accomplishment. Then of course you get code that hasn't been designed at all but instead has just been vomited up in repeated attempts to do something without any planning at all.

Make your code readable, appropriately documented, and straight forward. Don't try to be an uber coder. More often than not the things you think you're being clever about are just making your code worse. Don't over optimize or go crazy with cool options. Concentrate on maintainability.

Guess I should take my own advise. :)

Re:Something to note about other people's opinions

[kaens]

It should be relatively easy to extend the programming mode in emacs for whatever language you're using to do this. Emacs already has ways of making sections of text invisible, biggest problem would be marking comment regions - you'd need to look for comment flags (//, /*..*/,#,' depending on language), mark the region they apply to, and then hide that region.

Do it first through key-commands to hide the region and name it, and to show / hide all comments, then work on marking the regions automatically as they are entered (check out C-h v before-change-functions, C-h v after-change-functions).

You could even save comments in their own separate buffer with a small syntax for specifying the line they appeared on, or the context around them, and what type of comment they are (header, class, inline, etc) and kill to / yank from that buffer....

On second thought, it would probably be better to write this as it's own module instead of as an extension to a programming mode.......hmm.

Well, I'll stick this in my "Ideas to work on" file anyhow.

Re:Something to note about other people's opinions

[kaens]

The code is probably from "The C++ Programming Language" by Mr. Hard-to-pronounce-name.

He makes it rather clear in the book that he uses single-letter variables in places like that for illustration (and book formatting) purposes, and not as an example of what you should actually use for variable names.

Re:Something to note about other people's opinions

[Anonymous Coward]

filea.h

#ifndef FILEA_H
#define FILEA_H ...
#endif

fileb.h
#ifndef FILEB_H
#define FILEB_H ...
#endif

Re:Something to note about other people's opinions

[syousef]

If that's good code I'm a pretzel.

What are I and J representing exactly and why the fuck are you setting them to opposite ends of the range??

That's almost as bad as some code I ran across recently:

i *= 0;
j *= 1;

which would have been better replaced with

i = 0; /* j remains unchanged, no need to waste fucking cycles */

This was in some rather critical code. I was horrified!!!

Re:Something to note about other people's opinions

[Chemisor]

> except in your hungarian that would be:

Overuse of hungarian makes for unreadable code. There is no need to type your index variables.

> Of course, not everyone writes in C++...

And that's why not everyone writes good code.

Re:Something to note about other people's opinions

[Mr2cents]

It's more intuitive to find that programmers lack the TIME to just think. Courage has nothing to do with it.
The longer ANY programmer spends on the same code, the better it gets designed (if not written).
Really good programmers criticize themselves as they write and are almost never happy with a refactor. All three statements are correct. However, I fail to see the connection between them, and I'm not really sure where you're going.

Let's just start at the beginning. Do you really think I don't have deadlines too? Yet, while the rest is panicking, I'm taking a walk through the building, or looking through the window. I refuse to start coding right away. To me, this pays off: Once I have figured out exactly how I am going to tackle the problem, I need to write less code, debug it less and once it is in the field, I don't get as many support calls as some of my collegues. I get the job done and the customer is happy. But should you measure my productivity by how much code I write each day, I would be a lousy programmer. This is exactly what I mean by courage: in the face of deadlines, mass hysteria, panic and worried bosses, you need to sit back and relax.

Your second statement is beating a dead horse.

Your third statement... I don't know how you got there. Where did refactoring enter the discussion?

I'm not sure how that is helpful advice. You can't know how simple you can make something without usage. We come back to spending time reworking something you've already written. Once you see how other people (or just yourself) need to use it in the real world, you know how complex it *NEEDS* to be. Programmers are generally lazy and do not write things more complicated than necessary. When you start out sometimes it can get out of hand, but you come back to reality or dont ever come back. /For who, exactly, was that advice...insightful? What I do is I write an as simple as possible API, and I pretend it is already implemented. Then I can use it in the rest of my code and if it is insufficient, I rethink the API. Of course you cannot always foresee all the neccesary functionality beforehand, but that's something everyone has to live with. If you know a way to make a completely stable API right from day one, I'm very curious to know.

On the other hand, if you constantly need to change the API, it's a sign you haven't clearly defined what you're willing to abstract. Again, thinking about the problem will make it clear what you need and in 80% of the cases it will do fine without modification (rough estimate from personal experience).

And if you think everybody writes code as simple and short as possible, you're either not very experienced, or else I want to work where you do.

PS: I could be wrong, but from the tone of your post I conclude that you consider me some sort of babbling fool. Let me assure you, I'm not - at least not on this subject. Sorry if I sound arrogant (hey, you started it), but my IQ is 135, I've been programming for over 20 years now, and I really, really know what I'm doing. Don't mess with me ;-).

Re:Something to note about other people's opinions

[ILongForDarkness]

I think MS would probably have a better time with it, presumably they already know how to code "freeze panes", and they already have the concept of regions in their IDE. The problem is doing stuff like this dynamically hoggs a lot of resources. I hear people gripe about how long VS takes to load, but when you think about it, it is pulling your code out of source control, loading a GUI viewer and several text pages, scanning all the referenced code to fill in IntelliSense, etc etc, it isn't as simple as loading it in emacs, so there is an overhead. VS is a big beast but it gets the job done (I find it hard to live without IntelliSense now, though I can hack comfortably in VI emacs or even notepad for a couple thousand lines without too much trouble (assuming I'm not interfacing with a bunch of other peoples code that I really could use the help on).

Re:Something to note about other people's opinions

[anishpatil]

Until you are not saying it is commerce it hardly matters for me :)

Re:Something to note about other people's opinions

[angel'o'sphere]

Times are changing, and that is the biggest 'driver' against 'clean' code, it won't be long before the actual code will start to disappear. For some environments that is already happening.

I disagree: because computes become faster, and languages more specialized and also more focused on structure and readability the time should go towards better code, not more slopy one.

What good is it to write in python and then still write utterly unreadable and unmaintainable code?

angel'o'sphere

Re:Something to note about other people's opinions

[SilentBob0727]

If you can't handle people who don't think like you breaking the third commandment perhaps answersingenesis is a better forum for you to be commenting in.

Re:Something to note about other people's opinions

[SilentBob0727]

Sure, but once you've abstracted out enough that you can safely add two integers or look up a slot without everything blowing up, it doesn't look at all like C any more, and the extra layers remove any performance advantage C has, so what's the point? On the contrary, you can easily get polymorphism in C through use of function pointers. You can get encapsulation by defining a library of functions designed to operate on instances of a struct. Inheritance between structs is sloppy, but you can do it by including a struct instance as a first member then tacking more on at the end, then casting back and forth between pointer types. Hardly any performance is lost.

Sure, it's possible to write crap in any language. But can you give an example of an algorithm that can't be expressed clearly in a high-level language? I'd be curious to see it. I'm talking more about the business logic aspect when code gets segmented out into lots of little functions. Great for reducing code duplication, but it can be hard to grasp the big picture when you're looking at individual functions in isolation.

But as for algorithms where the intent is not clear from the code... How about the algorithm for calculating an MD5 sum, for one?

And some languages are better at expressing certain algorithms than others. Ever see a red-black tree sorting algorithm in Java? And then one in Lisp? Two guesses as to which one is easier to read. Ah, but you've already discredited Java.

you end up using object-orientation for a lot of syntactic things as well Not sure how you think this makes code less intuitive.

Java -- that's basically C with a GC ...and its own runtime assembly code, a virtual machine, a threading pool, dynamic linking, implicit pointers, type safety, ...

Re:Something to note about other people's opinions

[Anonymous Coward]

No way? How about this:

Range rangeI = m_rangeI.reverse();
Range rangeJ = m_rangeJ.reverse();

Re:Something to note about other people's opinions

[SilentBob0727]

Most likely a good compiler would have caught that and fixed it in the assembly. It's not an excuse for bad code, but its significance may not be as critical as you believe.

Re:Something to note about other people's opinions

[SilentBob0727]

Overuse of hungarian makes for unreadable code. There is no need to type your index variables. Just nitpicking. If you're going to use a bad practice, at least use it well.

And that's why not everyone writes good code. Mod parent funny.

Re:Something to note about other people's opinions

[Chemisor]

> Just nitpicking. If you're going to use a bad practice, at least use it well.

Since we are nitpicking, I would say that I do not use hungarian notation. It assigns variable names based on their type; I assign variable names based on their expected usage and their scope. For example the m_ prefix tells me where to find the variable, rather than what it is. I would also use type prefixes in cases where they say something important about how the variable is used. For example, "m_pDocument" is a better name than "document" because it explicitly tells me that this object does not own the document, and that the variable is to be used with -> instead of ., which is not always obvious. Other type prefixes can be used if they serve the same purpose. And as for the full hungarian notation, I'd say that m_lpszName does way more harm than good.

Re:Something to note about other people's opinions

[SilentBob0727]

And I'm in no way arguing that it's a bad idea. But it's ubiquitous among many C++ programs, and Windows C++ programs especially because all the tutorials use it (which is ironic because hungarian was designed for a language that didn't contain distinct data types). But what that means is it's still a good idea to learn to read it, so when you see lpszName, you think to yourself, "long pointer to zero-terminated string", not, "my God, what the fuck is that guy on?"

Re:Something to note about other people's opinions

[Anonymous Coward]

This is a pet-peeve of mine -- but in reverse. 2 spaces is fine, there's only 80 columns on a standard tty.

Get a real terminal to do your coding in. Even ISPF supports 132 column terminals.

Re:Something to note about other people's opinions

[fbjon]

I'll concede that that is acceptable as well.

Re:Something to note about other people's opinions

[syousef]

I hope you're kidding? Writing cryptic code that makes no sense is most certainly not something a compiler can catch. It's not what the computer does that's important in this case, its the maintainability of the code. I was the poor sap that had to try to figure out how that program works - that wasn't the most cryptic line either. One day someone's going to have to convert that code to run on another platform. You can bet your ass if it's me I won't be doing a dumb conversion. That code was gibberish and belongs in a C obfuscation contest not in commercial code. The fact that you don't understand any of this speaks volumes for the quality of your programming.

Re:Something to note about other people's opinions

[SilentBob0727]

Writing cryptic code that makes no sense is most certainly not something a compiler can catch. Actually, modern compilers are quite adept at optimizing arithmetic, so "i*=0;" could very likely become something like "and eax 0" and "j*=1" would probably be discarded. Which is very likely what the code you replaced it with would compile to. It has nothing to do with whether the code is sensible.

It's not what the computer does that's important in this case, its the maintainability of the code. Earlier you stated: "This was in some rather critical code." I assumed you meant cpu-critical, not maintenance-critical. That's usually what people mean when they say critical.

If the code *works*, is *critical*, and is in *production*, then unorthodox code be damned; you don't want to be a hero. Throw in a "wtf" comment and leave it be.

I was the poor sap that had to try to figure out how that program works - that wasn't the most cryptic line either. I've inherited shitty code too. Unless it's really atrocious, you don't bitch about it. You fix it if it needs fixing, and you move on.

The fact that you don't understand any of this Quite the broad assumption. I take it you think everyone who disagrees with you is a moron?

speaks volumes for the quality of your programming. The quality of my programming speaks for the quality of my programming.

Re:Something to note about other people's opinions

[syousef]

Actually, modern compilers are quite adept at optimizing arithmetic, so "i*=0;" could very likely become something like "and eax 0" and "j*=1" would probably be discarded. Which is very likely what the code you replaced it with would compile to. It has nothing to do with whether the code is sensible.

I wasn't disputing that the compiler could optimize. That isn't my issue with the code. My issue is that there is no excuse for making it so cryptic. I can only think that the programmer got bored, because there was no need to multiply a number by 1 or 0.

Earlier you stated: "This was in some rather critical code." I assumed you meant cpu-critical, not maintenance-critical. That's usually what people mean when they say critical.

No, you assumed that usage. It was critical as in vitally important. Where I am the word critical is used in that idiom all the time.

If the code *works*, is *critical*, and is in *production*, then unorthodox code be damned; you don't want to be a hero. Throw in a "wtf" comment and leave it be.

I didn't touch the code and wouldn't unless I had to. Unfortunately it's destined to be replaced in a completely different language. At that point it will make no sense whatsoever to make a verbatim translation of that cryptic crap.

I've inherited shitty code too. Unless it's really atrocious, you don't bitch about it. You fix it if it needs fixing, and you move on.

You're a coder right? We all inherit bad code, and we all "bitch about it". Just one more line down you accuse me of thinking any opinion that disagrees with mine is that of a moron. Yet you hyprocrtically decide to impose your own rather backwards set of ethical coding rules on me. I happen to think that if code is shitty you should let people know about it so it can be fixed.

Quite the broad assumption. I take it you think everyone who disagrees with you is a moron?

No I just call a coder that insists on defending REALLY bad code is a moron. There are plenty of other opinions that differ from mine that I respect, but certainly not yours.

Quite the broad assumption. I take it you think everyone who disagrees with you is a moron?

The quality of my programming speaks for the quality of my programming.

If you're a good coder and the code is being regression tested you should relish an oportunity to make code more intelligible. You on the other hand don't see a problem with code that looks completely crap and for no reason - in fact you're defending it because the compiler will probably optimize it. You blame others for your narrow interpretation of their words (ie. critical) and take zero responsibility for failing to clarify. I know all I need to know about the quality of your code.

Re:Something to note about other people's opinions

[Anonymous Coward]

Save the anecdotes on how you spend your time for your myspace. Saying that programmers just don't think enough translates into not having enough time. Stating programmers are simply NOT thinking is nonsense. I clarified the root cause.

Let's just start at the beginning. Do you really think I don't have deadlines too? Yet, while the rest is panicking, I'm taking a walk through the building, or looking through the window. I refuse to start coding right away. To me, this pays off: Once I have figured out exactly how I am going to tackle the problem, I need to write less code, debug it less and once it is in the field, I don't get as many support calls as some of my collegues.

my IQ is 135, I've been programming for over 20 years now, and I really, really know what I'm doing

The topic isn't about you specifically. The ad hominems and statements about how capable you are, reads loud and clear: troll.

Re:Something to note about other people's opinions

[SilentBob0727]

No, you assumed that usage. It was critical as in vitally important. Where I am the word critical is used in that idiom all the time. My bad. After all, people do assume things from time to time. Retracted.

I didn't touch the code and wouldn't unless I had to. Unfortunately it's destined to be replaced in a completely different language. At that point it will make no sense whatsoever to make a verbatim translation of that cryptic crap. Of course. I wouldn't dream of suggesting carrying over badly designed code into a rewrite.

We all inherit bad code, and we all "bitch about it". Just one more line down you accuse me of thinking any opinion that disagrees with mine is that of a moron. You came out immediately hostile. I have merely expressed my opinion and you have taken offense.

After a while maintaining someone else's crap, you expect to see bad code. Curiosities like i*=1 may elicit an "oh come on" response but they're nothing to write home about.

There are plenty of other opinions that differ from mine that I respect, but certainly not yours. There is really no need to get nasty and I'm not going to continue this discussion if you keep it up.

No I just call a coder that insists on defending REALLY bad code is a moron. I'm not "insisting on defending" the sample you provided. Frankly, I don't think it's god-awful-horrible to the degree you do. Yeah, it's bad. Yeah, it's unnecessary. But on the whole its effect is *maybe* one of a couple wasted cpu cycles and a minor headache (and one heavily flamed slashdot poster). I haven't seen the rest of the code, and obviously I'm not defending the entirety of this person's code.

You on the other hand don't see a problem with code that looks completely crap and for no reason - in fact you're defending it because the compiler will probably optimize it. I never said I don't see a problem with it. I do think it is bad code. We could be having this conversation without the attempts at bullying me.

You blame others for your narrow interpretation of their words (ie. critical) and take zero responsibility for failing to clarify. Again, I don't make a habit of pointing fingers, and I find your defensiveness and hostility ridiculously out of proportion to the issue at hand.

Re:Something to note about other people's opinions

[SilentBob0727]

Yet you hyprocrtically decide to impose your own rather backwards set of ethical coding rules on me. Talking about your opinions regarding code maintenance practices hardly qualifies as imposing, let alone hypocritical.

Re:Something to note about other people's opinions

[Anonymous Coward]

To me, while the parent is well written and well thought out, it is emblematic of what I view as the true problem. More than once the author declares this or that as simply and unequivicably "wrong".

Now, that's just plain wrong.

Ok, now that I have amused myself. I have no idea what the author's qualifications are or where his expertise lie, but even if your name were Pascal or Mitnik, I would still baulk at you declaring anything other than a memory leak or endless loop as simply "wrong".

You have no more right to declare this than I do. And when we start throwing around acusations like "you are wrong" the conversation almost always and immediately goes off track and we are no longer discussing what good practices are, but rather who is and who is not wrong on a topic that is almost entirely subjective.

I could point out that this author writes something approaching or passing 1000 words and the entirety of his soapbox is limited to commentation. This, is wrong. Ok, amused myself again...If I have a choice: get someone to name their stuff better (please for the love of god people, lets start getting militant on nounAdjective naming, now there is a worthy cause) as opposed to them commenting public procedures, I will go with the former each and every time. If you name the method well, I don't even have to read the comments. Would I like some comments? Oh yes, I would very much thank you. But would I rather have Add() with 30 lines of comments or AddDaysToList() with not a single comment...well, my preference is obvious. I will leave it to others to declare this incorrect.

Re:Something to note about other people's opinions

[Anonymous Coward]

No Agile-nazi here, just a wee-simple codemonkey, but would ask the question...

What is wrong with
InitializeOppositeEndOfRange(nIMin, nIMax);
InitializeOppositeEndOfRange(nJMin, nJMax);

My only point, the entire topic is really silly.
There is only one thing (for us nonXnix-hippies who have families to feed and what-not ;) that defines "good" code: does it make money. If it takes the maintenance guy 100 manhours to do a quick fix, then I don't care what your code looks like, or how well YOU THINK it is written, it is bad code. Yah, boo-hoo, but that's the real world. I am highly sought after in my organization for inputing my 2cents on projects and coding...why? Because I am some code god? No, far from it. Because I know that using the newest thing does not make one cooler, nor one's code better, and I write code that a monkey could follow. Could I put a lot of really ubb3rc007 tertiary operators and the like? Yes, I could. However, I get promotions and raises and am sought after because I do not. I write code that can be compiled into efficient binary, but more importantly, can be read by a project manager (not a marketing PM, let's not go overboard).

Re:Something to note about other people's opinions

[syousef]

Talking about your opinions regarding code maintenance practices hardly qualifies as imposing, let alone hypocritical.

It does when you impose them on other people (ie. criticising me for "bitching" about bad code), then violate them yourself (bitching about my criticism of the code). Too bad you can't see that.

Re:Something to note about other people's opinions

[syousef]

You came out immediately hostile. I have merely expressed my opinion and you have taken offense.

You're right. I was a little more hostile than necessary off the bat. I took offense to you saying the code wasn't bad. It's not the worst I've seen (I've actually seen code pranks triggered on april fools in live code that told the user their computer was being erased). It's definitely not good code.

After a while maintaining someone else's crap, you expect to see bad code. Curiosities like i*=1 may elicit an "oh come on" response but they're nothing to write home about.

There wasn't a single instance of this in the code. It was a short program (few hundred lines), and strewn with code like the above. (Several cases of those two lines for starters). It's hard to follow and I dread the idea of rewriting it.

I'm not "insisting on defending" the sample you provided. Frankly, I don't think it's god-awful-horrible to the degree you do. Yeah, it's bad. Yeah, it's unnecessary. But on the whole its effect is *maybe* one of a couple wasted cpu cycles and a minor headache (and one heavily flamed slashdot poster). I haven't seen the rest of the code, and obviously I'm not defending the entirety of this person's code.

Sorry but that sounds like a defense of it to me. There's no reason for code like that. None whatsoever. A programmer should be making every attempt to make code easy to understand and this seems like a willful effort to go the other way. There's no way that simplification wouldn't be obvious to anyone writing the code. Someone spent time making this code hard to understand, and they were PAID to do it. That in my book is unforgivable. Not a lot different to a mechanic you're paying to fix your car purposefully doing damage to other parts of it.

The couple of wasted cycles doesn't matter at all. It'd have to be in one hell of a loop for me to care about that.

I never said I don't see a problem with it. I do think it is bad code. We could be having this conversation without the attempts at bullying me.

I apologise if it comes across as bullying. I completely disagree with your assessment of the code. I think the programmer that wrote that was not being professional and should be taken to task. A programmer who writes bad code because he knows no better, or due to circumstance is one thing. A programmer that obfuscates his code because he's bored doesn't belong in the profession.

Re:Something to note about other people's opinions

[Anonymous Coward]

int nIMin = m_nIMax; // initialize to opposite ends of range
                                int nIMax = m_nIMin;
                                int nJMin = m_nJMax;
                                int nJMax = m_nJMin; Bug!

If you tried to pull a stunt like that on my team (commented or not), I'd gently sit you down, and together we'd write this:

            assert ( m_nIMin <= m_nIMax );
            assert ( m_nJMin <= m_nJMax );
            assert ( nIMin <= nIMax );
            assert ( nJMin <= nJMax );


And then we wouldn't check-in until we passed the unit-tests without an assert.

Max is never less than Min. Anything else is a bug.

http://en.wikipedia.org/wiki/Principle_of_least_astonishment

Re:Something to note about other people's opinions

[SilentBob0727]

It's definitely not good code. And again I state, no argument there. I think we disagree upon the degree of severity of that particular snippet you posted. Had it been an isolated case (and that's how I took it in context of your original post -- I understand now that it was all over...), and among generally OK code, you might possible agree with me to a greater extent.

Honestly, though, those wouldn't stand out to me as gloriously awful code in an ocean of bad code. And no, I wasn't criticizing you of bitching though I apologize if it came across that way. I usually save my bitch sessions for real gems like when a coworker denormalized one table into another one five times, then repeated the business logic in the code five times, in order to ensure that the relation always had exactly five members, rather than just write a damn commit hook.

Sorry but that sounds like a defense of it to me. Again, just disagreeing about the overall severity of that isolated instance. I don't make a habit of defending bad code but I do try to put myself in the bad coders' shoes and try to figure out what their thought process was. For instance, maybe he had a weak grasp of pointers and was trying to write *i=0 and *j=1 from something he saw online and didn't exactly understand why, and found out that moving the asterisk over one resulted in compiling code and figured that was correct. Whatever. I wasn't there.

Someone spent time making this code hard to understand, and they were PAID to do it. That in my book is unforgivable. Not a lot different to a mechanic you're paying to fix your car purposefully doing damage to other parts of it. I haven't seen the code, but I would *suggest* not to attribute to malice what can easily be explained by incompetence. Though I would certainly not want this particular coder working on a team with me.

I do want to make clear, however, that the last thing I'm trying to say is bad code is OK and I apologize if I have come across as hostile in doing so. And the only thing we appear to disagree on is perhaps how severe one isolated instance of that particular code would be.

Re:Something to note about other people's opinions

[jebblue]

I served in the military to defend your right to think like you want and my right to express what I think about it.

Re:Something to note about other people's opinions

[jebblue]

I've thought it over some more, I should have just ignored that part of your post. I apologize.

Re:Something to note about other people's opinions

[kaens]

>I think MS would probably have a better time with it, presumably they already know how to code "freeze panes", and they already have the concept of regions in their IDE.

True enough. Shame you couldn't just add it to the editor though (or can you? I honestly don't know much about the extensibility of VS). The main reason I use emacs a lot is because it lets me customize the way I edit code - on the fly, whenever I feel like it, however I feel like it.

Not that emacs doesn't have it's quirks - there is some ugliness in it, but I think that most of it is anachronism.

>The problem is doing stuff like this dynamically hoggs a lot of resources.

Also true. I can't think of a way to do dynamic code-folding that wouldn't hog a lot of resources (respectively, anyhow - I think most comps are fast enough that you wouldn't notice very much overhead unless the person that wrote the code didn't do it in a speed-optimized manner) - but there are ways to minimize it.

You could, as an example, save the buffer containing the simple syntax for specifying comment-folding in a file, and save a list of files known to have it, and their associated comment-folding-syntax files - which could reduce a lot of the overhead when opening a file (except for on the first time). There would still be overhead, but not "parsing the file like freaking mad" overhead.

Lisp would make this rather easy to do; I'm not sure if Elisp will (I haven't hacked it to quite that depth yet - here in a few days though...)

You're right about Intellisense being nice. It's damn nice. I mean, I don't even really need to know the libraries I need to use to write code when I write code in VS - I can normally just take a logical guess at the name, and have it there for me.

P.S. - I'm not too versed in VS. I hardly use windows, and I really don't like Excel - So I may be missing out on the methods that exist for extending VS, if any, and I may be implementing things horribly wrong by guessing at names and letting Intellisense do the "work". (But then again, it tends to work.)

Regardless of all that - thanks for giving me an interesting idea to code in my free time.

Re:Something to note about other people's opinions

[syousef]

And the only thing we appear to disagree on is perhaps how severe one isolated instance of that particular code would be.

I can respect that, especially since we're unlikely to ever work together on code and therefore I guess it's academic. We've both clarified our positions and retracted hostilities. Let's let it go at that.

Re:Something to note about other people's opinions

[Anonymous Coward]

I recently had a programming problem that I thought two weeks about.

if they wanted someone who would always seem busy, they hired the wrong person

It is a bit embarrassing if your boss enters your office and you're just leaning back in your chair, day after day

HAHAHAHA.... AAAAAAAAHAHAHAHAHAHA. Seriously dude, enjoy your unemployment. Jesus fucking Christ.

Re:Something to note about other people's opinions

[zerosigns]

Yes, you are absolutely right. Your code is yours, you are best at it. One cant easily understand others code, because its others'. Thats why it sucks.

Re:Something to note about other people's opinions

[sticky.pirate]

Your example is clear and easy to understand, but unfortunately you still need to read the code. You've done a great job of making sure your code matches your comments, but after 2 or 3 maintenance cycles involving code-monkeys, I think the odds are that the comments wouldn't get updated and would no longer match the code.

You always have to read the code. The really fun part is trying to figure out, when the original developer is long gone, if there's a bug in the code, the comments, or both.

Re:Something to note about other people's opinions

[ILongForDarkness]

There is huge extensiblity features in VS. Everything that VS does is available as an API that you can develop to and plugin to VS. There is over 650 companies making there own compilers that plug into VS, some complete with syntax highlighting and IntelliSense. Your right about the idea of caching the comments, probably doable as you can append to that file as you code more so it stays current.

Emacs is my editor of choice on a UNIX or Linux environment, but I still like to call the compiler from command line (not sure why, just the way I do things :).

Re:Something to note about other people's opinions

[SilentBob0727]

I served in the military to defend your right to think like you want I respect that. But that means you defended people's right to do things that you believe to be an affront to God. Military service does not give you the right to tell civilians what's right and wrong.

my right to express what I think about it. Then say you believe that type of speech is disrespectful to your God and find it in poor taste. I will at least respect that but I will be free to disregard it.

However, you might be better served picking your battles more wisely. I'm pretty sure God is more pissed off about stuff like crime, poverty and injustice than a bunch of people saying his name the wrong way.

Re:Something to note about other people's opinions

[kabz]

Moving big-ass flat files of data around is still reasonable practice. I've seen code where the fastest way to get data into a system after processing was to spool it out to disk, then call a bulk loader.
Of course if you want to be *fancy* you can use an XML file instead of plain text or CSV, but aside from having to link in more libraries, it doesn't seem to buy you much.
I remember the great XML craze. Boy, that one didn't solve many problems.

Re:Something to note about other people's opinions

[boyfaceddog]

One. You can have cleanly written code that follows this or that coding school. The code will have the correct number of comments to explain what the programmer meant but nothing else and only where absolutely necessary.
Two. You can have code that does exactly what the user expects. Further more the code has enough comments so you can hook on all the bells and whistles that your client wants.

For me, I'd pick number two any day and twice on Sunday no matter what the code looked like. Performance over design.

Re:Something to note about other people's opinions

[QuietObserver]

I'd actually say that codes not nearly as bad as what I found in the original Metroid's Sound Driver, which repeatedly used the following contexts (this is in 6502 assembly):

All instances of performing a fixed value compare of the X register (the efficient method is CPX #):

TXA (Transfer X to A)

CMP #$ (Compare A)

The Same goes for doing the same with the Y register (the efficient method is CPY #), with TXA replaced with TYA.

And then there was a section of code used to determine what function to call based on the highest set bit in a source value initially stored in A:

LDY #00 (clear the Y register) STA $ (store A in memory) loop: ASL $ (shift a byte in memory one bit to the left)

BCS exit (branch to the function call if the shifted bit was a binary 1)

INY (add one to Y)

INY

TYA

CMP #$

BCC loop (this repeated the loop until Y reached the ending value)

This function had quite a bit of overhead, as well; I simplified the entire subroutine (overhead and all) to a very simple function that does the exact same thing:

LDY #00

loop:

ASL A (shift A one bit left)

BCS exit

INX

CPY #

BCC loop

That said, I'm actually a very poor coder; my comments, when I remember to add them in, are decent, but most of my code somehow fails to do what I intend, and my debugging efforts fail far more often than they succeed.

Re:Something to note about other people's opinions

[dragonturtle69]

Very true, that out of date comments are next to useless.

Re:Something to note about other people's opinions

[damonmc]

In the right language, implemented the right way, code can be nearly as readable as the comments, modulo the function names used by the underlying APIs. Not that this necessarily means the should necessarily be removed: they're still a useful check that what is implemented matches the intention. But when possible, a commented piece of code should be structured so that it clearly implements the idea in the comment, and only that idea. For instance, I think that your example code could be improved by doing all the filtering (on both scope and currency) in the first loop, so that the second loop doesn't need to both make the change (as indicated by your comment) and update the total (which isn't even mentioned in the comment).

As an example of what is possible in modern languages, here's a python 2.4+ translation of your code with the pseudo-hungarian prefixes stripped from variables. I assume that the abbreviation "CCy" for currency is standard across your code base and thus obvious for anyone working with this code. I realize that the list comprehension syntax used in the first 2 lines of code--and the generator expression passed to sum()-- might not be completely readable to someone who doesn't know the language, but that's true for the idioms of any language (and I assure you, they become very readable after using them for a short while).

# get securities in current scope that have the relevant settlement currency
securities = [s for s in allSecurities if
              s.currentScope()==enScope and s.settlementCCy()==sCCy]
 
# apply the change to each of these securities
for s in securities: s.makeAChange(newValue)
 
# compute a total of the new market values for these securities
total = sum(s.marketValue() for s in securities)
 
# handle case of account going short (i.e. total is negative)
if total < 0: account.handleShortChange()

You may not have the luxury of ditching VB for Python, but I wanted to illustrate how a language designed for readability really makes a difference.

One final point: Code should be written for readability first, and efficiency only where it is significant. Not to say that you should write grossly inefficient code, but since most code is not in the inner loop, it usually makes sense to write code in the most readable way unless you know it to be performance critical. If you can make it more efficient without sacrificing readability, all the better. So I don't believe you need to give disclaimers about looping over your collection twice instead of just once when illustrating a point about readability. Similarly, I make no apologies about my code's 3 loops. If the code is performance critical and loop overhead is really significant, it is trivial to transform it to something like the following:

# initialize new total value of securities in current scope, having the
# relevant settlement currency
total = 0
 
# for each security in current scope having the relevant settlement currency...
for security in allSecurities:
    if s.currentScope()!=enScope or s.settlementCCy()!=sCCy: continue
 
    # apply the change to the security
    for s in securities: s.makeAChange(newValue)
 
    # update the total to reflect the market value of this security
    total += s.marketValue()
 
# handle case of account going short (total is negative)
if total < 0: account.handleShortChange()

Re:Something to note about other people's opinions

[PastaLover]

Does that even work? Where do you reverse the range? And what's up with the two letter variable names?

Re:Something to note about other people's opinions

[PastaLover]

Talking about limited imagination, I see no error. There's no assignment to the m_* variables AFAICT. The fact we're even having this issue shows clearly the code is utterly unreadable though.

Yeah, not a very good example. :-)

Re:Something to note about other people's opinions

[PastaLover]

I'd just like add that to the original poster I would recommend picking up some programming/design books from various schools of thought. One I could recommend is Refactoring by Martin Fowler.

In his opinion (which I happen to share) refactoring is a way in the very short term to make your code cleaner, easier to understand and modify, allowing you to work faster in the long term. You're a professional for crying out loud, don't let your boss tell you how to do your job. He's there to tell you what to do, you're supposed to take the fastest way there, which is usally not by hacking it all up. Not if there's a chance you'll be working on the code for longer than a week or 2. This aligns nicely with the parent's post of course but it can't be said enough. Faster in the short term is almost never faster in the long term.

And if your boss doesn't agree with you using refactoring techniques or taking time out to review and clean up your code, just don't tell him. As long as you get the job done right?

Re:Something to note about other people's opinions

[GWBasic]

A second advice would be to keep abstractions as simple as possible. Think "What do I need and what API do I need to do that?". If you can get away with an API with only an init function and a "worker" function, then be my guest! K.I.S.S. is very important. Again, to make things as simple as possible requires a lot of thinking.

I hear that! Too many abstractions can ultimatly make things worse, especially if the abstraction layers are highly specialized and take hours to debug!

Re:Something to note about other people's opinions

[Anonymous Coward]

WRONG! The code should be:

Dim total as Double = GetSecuritiesForCurrentScope()
ApplyChangeToSecurities()
if total 0 then oAccount.HandleShortChange

Private Sub GetSecuritiesForCurrentScope()
avItems = dctSecurities.Items
for nCtr = 0 to dctAllSecurities.Count-1
        Set oSecurity = avItems(nCtr)
        If oSecurity.CurrentScope = enScope Then
                    colScopeSecurities.Add oSecurity
        End If
Next nCtr
End Sub

Private Sub ApplyChangeToSecurities()
dTotal = 0
For each oSecurity in colSecurities
        If oSecurity.SettlementCCy = sCCy Then
                oSecurity.MakeAChange dNewValue
                dTotal = dTotal + oSecurity.MarketValue
        End If
Next oSecurity
End Sub

When you think you need to write a comment, think instead whether you can write a function that would replace the comment.

Re:Something to note about other people's opinions

[IngramJames]

heh.. yeah, I know my sample code was inefficient.. it wasn't written for what it did, so much as I wanted 3 code blocks, and didn't want to post real production code, so I made up some rubbish stuff :)

Actually, my initial comment *did* include remarks about totalling, but I took them out; the point I was trying to make is that the totalling was less likely to have happened in either of the other two blocks, so the middle block (from comments alone) was where you should start looking. My example wasn't terribly realistic.

I like the look of your code - and yes, our code basically *has* to be written for performance - everywhere. We deal with large grids of data; multiple loops make the system unresponsive.

Re:Something to note about other people's opinions

[IngramJames]

Absolutely you still have to read the code. And if the code-monkies damagae the comments, then they don't get their bananas :)

Re:Something to note about other people's opinions

[IngramJames]

Interestingly (on while we're on the topic), my boss (who sits next to me) just found a 13-line comment (followed by a one-line fix), which I left in the code a couple of years ago.. he's looking at a bug, and right bang where the code took him, there's the massive great big comment...

The comment described a thorny GUI issue, why it would happen, how the code below fixed it, and what the parent control should do to handle the fixed behaviour. He could then use that detailed knowledge to make a fix in the parent component, which was handling events ever-so-slightly incorrectly under certain circumstances. I reckon that's probably saved him at least half a day's work.

Which is nice :)

I don't advocate huge comments normally, but when there's complex behaviour which isn't obvious (in this case the order in which windows events fire, depending on where the mouse starts/finishes), it is fully justified; I'd go as far as to say necessary.

Re:Something to note about other people's opinions

[LaurensVH]

Just use 1-dimensional, two-element arrays for ranges (it works for me). That way, it turns into: @range = reverse @oldrange;

Re:Something to note about other people's opinions

[supersnail]

Programming languages (since COBOL) were designed for humans to read.

The first language FORTRAN was designed for mathemeticians rahter than humans but the prinicple still
holds.

Computers were very happy with lists of machine instructions.

The only real question is easy is it to express to solution to a complex problem in the language
of choice. For me the overall winner has to be Python -- most code is about the problem, logic
is clearly expressed, complex concepts can be hidden as apparently simple objects -- wonderful stuff.

The clear loser is Java ( apoligies to Java fan boys but I am currently rewriting a fast clear high performance php
application as a complex , hard to read badly performing J2EE app because this is somehow "standard") -- its more
of an educational tool for illustrating abstract coding concepts than a practical language. An enormous amount of code,
I would rekon 50%, is purly about java rather than the problem at hand and which idiot thought "System.out.println()" was somehow better than "print"? Even worse because no one will admit any indadequaces in the basic language we are stuck with thoughands of competing frameworks which do stuff the language ought to do out of the box.

Re:Something to note about other people's opinions

[joaommp]

Is it my dislexy or your getting it wrong? Your attributting the same values and not inverting the ranges as the example you contradicted does.

Re:Something to note about other people's opinions

[Anonymous Coward]

apologies for the VB

Accepted.

Re:Something to note about other people's opinions

[demallien2]

I couldn't agree with you more. Sadly, having tried this style of commenting/documenting at my last couple of jobs, I'm ready to give up.

I've tried writing large block comments at the start of a module, explaining what the module does, and then comments in a block before each function of the module, explaining how that function fits into the big scheme outlined in the big comment above. I've tried doing pretty much the same, except putting the large comments that were at the start of the code module in a seperate architecture document. I've added UML diagrams to said doculent to make it clearer. I've put the comments both in the module, and in a document at the same time. I've written additional documentation explaining how the code artifacts (objects, files, variables) relate to the terms used in the specification.

And you know what? No-one bloody well reads the stuff. People figure that it's easier to come to me to help plan out a modification than to read the comments which would have answered all of their questions if they'd just taken 10 minutes out of their oh-so-busy lives. As that level of documentation typically takes 2-4 weeks to write, depending on the size of a project, I have come to the conclusion that it's a waste of time, and that I could better spend that time by writing bigger and meaner unit tests. That way when an idiot modifies code in a module that they haven't read the documentation for, and hence don't understand, their scope to actually wreck the system is limited.

Re:Something to note about other people's opinions

[demallien2]

Ouf, Google translator still needs some work. The French translation should look something like this (apologies to actual native french-speakers...):

Les programmeurs "agile" ont raison. Si le code est bien écrit, il va parler pour lui-même. Il n'y a pas besoin de dupliquer ce que dit le code dans un autre langue(par example anglais). C'est un peu comme si tu commentais tes paragraphes anglais avec la traduction française. à moins que le français soit ta langue maternelle, de tels commentaires ne vont qu'obscurer la lecture de l'anglais. En tant que programmeur, c'est mon boulot de "parler courrament" mon language de programmation de choix. Lire du code devrait être aussi facile que de lire un bouquin. ...

Célà dit, parfois on est obligé d'écrire quelque chose d'anormale, et dans ce cas, on devrait le commenter. Pourtant, ces cas sont très rares..

I suppose I should explain why I just corrected (as well as I am able) the translation. I work for a French company - all of the programmers are French, except me, and yet they have a stupid corporate policy where all comments in code should be written in English, as are identifiers (variable names, function names, type names).

The result is that comments are very sparse, and generally limited to simply repeating, using fixed phrasing, what is already très clair in the actual code. On the few occassions where somebody actually tries to go a bit further, the lack of mastery of little things like prepositions (in, of, to, at, on, in), which is fine in day to day speech, can sometimes completely destroy/inverse the meaning of a comment, making it worse than useless.

Now, with programming being such an international endeavour, it is becoming quite rare that all of the programmers on a project have the same native language. In such an enviroment, bastardised English comments are next to useless - non-native English speakers won't read or write them, and native english speakers can't understand what has been written by non-native speakers.

My conclusion from all of this? Forget about documentation. Try to make the code as self-documenting as possible. With the time saved from not havig to write documentation, write unit tests instead. Your code (and the world) will be better for it.

Re:Something to note about other people's opinions

[CuriousCuller]

I couldn't agree more... on an unrelated, but comparable note: Joseph Heller had "Catch 22" turned down dozens of times before it was published. Most editors (who are invariably failed writers IMHO) sat down, read a few pages and stuffed his manuscript in the shredder. Stephen King used to keep his rejection letters on a 6" nail until he ran out of space....

The moral of the story is that everything's subjective in life and all creators, be they writers, artists or programmers are extremely self-critical of their own work, but more than that:- peers are even more cynical and critical than others. I bet even Tolkien had a few "thanks, but no thanks" letters in his time, and I bet he felt his work was sub par after a or dozen two. A middle finger after success still remains the best cure and just because everyone says your creation sucks it doesn't mean it's true.

Same here

[polar red]

the problem is... the client doesn't always know what he wants, and the continuous changing of the specs (and hence of the code) make it a mess. It gets worse when near release some 'minor' changes have to be included and a lot of code has to be written in a very short time. There's a big difference between the theory of the 'waterfall-model'(and it's derivatives) and reality.

Re:Same here

[Anonymous Coward]

sig grammar alert: "as if it were life itself," unless there is some irony / joke this AC is missing ...

Re:Same here

[ByOhTek]

That, and "convincing the boss the customer isn't always right is a dumb and pointless thing for several reasons"

1) The bos probably already knows this is some respects, however...
1.a) Should the boss act on this knowledge, he or she will lose the customer, this is not profitable
1.b) The company could get a bad reputation of not following the customers requests, losing more potential customers
2) The customer, in the end, knows if the product is functional or not in their environment, better than you do. If you think otherwise, you need put your arrogance in check so that you can produce useful quality code.
3) The customer, in the interim, still knows their situations and setups better than you in most cases. While they may need to change requirements for overlooked circumstances and situations, that doesn't mean they don't know what is going on.
3.a) Pointing out that they have missed something isn't necessarily a bad idea though, if you do it in a respectful manner. This can actually improve their perception of the quality of your work.

Re:Same here

[Anonymous Coward]

The problem is, as your project's deadline approaches, then recedes, the "Waterfall Model" often becomes the "Yellow Cascades" model...

Re:Same here

[YeeHaW_Jelte]

If you work with specs (in a hewn-in-stone way) you can expect them to change ... your code should reflect this and as flexible as possible so that it can change to absorb these changes in a decent way.

To achieve this, you should try to work in a modular fashion, splitting as many logical components as possible.

That said, there's always a change around the corner you didn't anticipate.

Re:Same here

[WallyDrinkBeer]

I've pretty much worked as a maintenance programmer for years, seen some horrible stuff. I have to agree that the environment in which the programmer is put makes a big difference.

I'm currently working on undocumented poorly conceived rubbish. One could blame the previous programmers but if you speak to the managers there, they don't spec anything and are unwilling to even talk about the systems...

Why, because they're not really sure what it should do, they just have some vague notion... They ask for a vague idea to be implemented and leave the poor graduate programmer saps to come up with something that meets their needs.

My advice - don't be quick to criticize your predecessors, you haven't walked in their shoes.

Re:Same here

[computational super]

Yes, the boss probably knows a thing or two - that's why he's the boss. Yes, the client probably knows their business, because it's their business. What nobody seems to understand is that every requirements change impacts the delivery date. I don't mean this facetiously; they really don't seem to understand this at a fundamental level. They're always full of "helpful" suggestions to try to keep the project on target no matter what changes they make to its definition. Adding manpower to a late project makes it later. Overtime = 10x the bugs, longer QA, later delivery. Removing features is still changing requirements.

I wouldn't mind constant requirements shift if they could deal with constant delivery date shift.

Re:Same here

[miltonw]

I've found a system that minimizes scope creep quite well. Tell whoever requests the change, "Any change of spec means, of course, change in the estimate. I'll work out what this change will do to the schedule and budget. As soon as that's approved, we'll incorporate the change into the project."

Most times, the users suddenly discover they really don't need that new feature. But, if they still want it, the schedule and budget are adjusted to match.

I know, I know, sometimes you get the order to incorporate the change without more schedule or budget -- then you just make sure it is documented who approved the change that screwed up the schedule and budget.

Or, you can ignore all this and just whine while your project goes into a death spiral. That's always fun.

Walt

Re:Same here

[ByOhTek]

This sounds a lot like a project I've worked on recently, except the boss (especially) and the customers are all exceedingly aware that the project will be out later at a higher cost with each change to the requirements.

But, what it comes down to is a simple fact; it's better to have a late product that works, than one on time that doesn't.

Re:Same here

[Anonymous Coward]

I have this mantra that I code and live by "The client dosen't know what they want, until the developer tells them". What this means is that the client has an idea that he wants made into a reality. But to figure out what they want you have to show them something. This something also called a prototype usually is also the basis of the production code. Not the best solution but most times it is what management wants. I find that this can lead to really unmaintainable code.

Re:Same here

[Hognoxious]

"Were" is correct, it's a subjunctive. The error is that "it" is singular and "ideas" is plural.

Re:Same here

[Hognoxious]

The customer, in the end, knows if the product is functional or not in their environment, better than you do. If you think otherwise, you need put your arrogance in check so that you can produce useful quality code.

If only that were true. In reality, they start meddling in the implementation details - which they know nothing about, but they don't know that they don't know. Well it's just typing, isn't it?

I saw a classic on /. some while ago about a customer who demanded a save to the database every screen change; what he needed was that they don't have to rekey data from a prior screen. Of course it was the programmers fault that the app was uber slow when you got more than 10 concurrent users...

Re:Same here

[tknd]

the problem is... the client doesn't always know what he wants, and the continuous changing of the specs (and hence of the code) make it a mess

Is that really the only side of the problem? From this, you're assuming that the developers are able to adequately translate what the customer says he wants into appropriate specs but that's far from reality. The truth is many developers are really bad at obtaining requirements and it is only more complex when the customer is not good at it either. Now you have two entities incapable of communicating ideas trying to find a solution, together. As one can imagine, that will only lead to many failed attempts before an adequate solution is found.

It is quite sad because most undergraduate CS majors are not taught requirements engineering. At my school I was lucky enough to have the option of taking an advanced requirements engineering course that specifically dealt with understanding the complexities and issues in requirements engineering. In the first lecture one of the first activities was to guess what type of object our professor was thinking of with no information. He merely said, "I'm thinking of an object, what is it?" Of course nobody could answer his question, so he told us to ask him about the object. Students naively started with questions that were too direct, like "Is it a book?" To which our professor would answer, "No." After his answer he would ask us a question, "Did this question get you the information you wanted?" And of course the student would say no. Students continually tried asking questions until they realized they should not be asking questions about what the object is, but questions that would get them information in classifying the object. The key point in this lesson is, every question you ask must have a goal in gaining you information regardless of what the answer is. That is not an easy task, but it can be done.

Another missed issue in requirements I've seen to date is they completely ignore the problem itself. They go straight to documenting different traits of the software to be produced rather than addressing what problem(s) the software is supposed to solve. We don't build software because we want to, every piece of software built is built to satisfy a problem that other types of software did not solve or do not solve well. The first item in any requirements document should be a problem statement--the overall issue your software addresses. It even applies to things that seem like they solve no problems. Take for instance a video game. Video games don't solve problems, do they? Actually they do. They entertain people, they provide experiences for people that are not possible in the real world.

The final issue that plagues software engineers and programmers is lack of social and communication skills. In my requirements engineering class, we did not touch one line of code or even one UML diagram. Use cases are fine and dandy, but you can't get to a use case unless you really understand what you're customer wants. If you go straight to use cases you're back to guessing things just like the "Is this a book?" question. Everything was focused on dealing with the customer. That meant issues like talking to the customer, negotiating with the customer, and being able to translate what the customer said into requirements.

At the end of the day, the customer can be whoever they want to be and have incredibly bad communication skills. They can ask you for the world and you can't say anything other than refuse their offer. The reason why they can be bad customers is because they have the money. If you want their money, you have no choice but to get better at requirements engineering.

Re:Same here

[mkiwi]

the client doesn't always know what he wants

I hear that. On a large project last summer I had one of those "can we add feature x and y and z" jobs. I was only there for the summer (as an intern in software engineering) and the code, to my knowledge, never got finished. It was an web-based administrative tool for Active Directory and MS Exchange. I know I know. That's one of the things they knew they wanted.

I ended up figuring out how to make the code smaller, more elegant, and more powerful and I ended up redoing three pages to make all my code perty. Then I got a "stop development" message when their company's VPN was connected to their China office. It turns out accounts were being locked out systematically, a-z down the tree. They thought it was me.

Actually it was an issue with the firewall/router in China set to accept *.* for ip addresses (that is not meant to be an emoticon, although as an emoticon it would describe many things about this problem). It cost the company two weeks of time getting it resolved, it pushed my project back, and we were unable to finish documenting the code and its API's, much less installing it on a server. They were all windows-based- I used things like Java, PHP, MySQL, etc. to interface with the Active Directory anyway because I do not program VB and I do not deal with COM objects. It also helped that I was the only Engineer working on the project and I like to Do The Right Thing(tm).

That was on tangent, but the comment is not good without the story. (How can an IT department do THAT? And for two weeks?!) Because feature x and feature y and feature z where added to the code base there was no time for me to document the API or much of the program before I was back off to school.

it keeps us employed...

[Dr_Art]

I think quality in general has gone down over the years. In IT, I've seen that pushing quality is career limiting. There's definitely a lot of people making lots of money with the current state of things. I'd suggest you do what you can to improve your own code quality and soon you'll stand above the others.

Regards,
Art

This Should Explain It

[explosivejared]

If so, then what is holding you back from realizing your full potential?

This post should explain it. If you think hiring practices are discriminatory for minorities, try being like me!

Cherish YOUR THUMBS!

Re:This Should Explain It

[Slashidiot]

A dog's code doesn't need to be buggy, unless the dog has fleas...

Getting better.

[Ihlosi]

It is buggy, slow, fragile, and a nightmare to maintain.

When looking back at my first project, I feel the same. But I also think that I've learned a lot from it, and all subsequent projects were much, much better.

So, by being "not proud" of your code, you've made the first step towards improving it.

Re:Getting better.

[RandoX]

If you start coding from the beginning with the best possible methods, then congratulations. If you're like myself, and most of the rest of us, you're learning better ways to do things as you go. I know that I can't help but look back at older projects and think that there are better ways to do what I've done. Now I know better. Now I'll write things in a more efficient and maintainable way. I can only hope that in a few years I'll look back at the code I write this week and have an even better, cleaner, faster, and more maintainable way to do it.

Re:Getting better.

[tompatman]

I agree with this, and I code better now than I did a few years ago. But I still maintain the work I did as a contractor a few years ago and even if some sections are messy it is easy enough to understand and modify without rippling bugs throughout the system.

The code I am supporting now is often "Over organized". Several modules are created to accomplished simple tasks, several layers of functions have to be sifted through to get to the meat of what is going on, many of those functions being only a few lines long and there are MACROS galore, continuously renaming a function to something else.

In comparing the two, there's lessons I've learned about good coding practices, like consistency in naming things. But another thing I've learned is that creating a new function every few lines is not better for readability or maintainability and would gladly take my messy overstuffed functions any day.

Re:Getting better.

[JackHoffman]

My solution: Avoid looking at your own old code. It's a bit like looking at pictures of yourself in 70s/80s/90s clothes. What the hell was I thinking? If you extrapolate from that experience, it hits you hard: The current code sucks too, and the clothes don't compensate for that any more than they did back then.

You really have a problem when you look at your old code and clothes and find nothing wrong with them. Of course, if you're sufficiently famous, that's called "style."

Re:Getting better.

[Thanshin]

I've always felt I do things better each time I try again. Programming is simply one of the areas where it's easier to see. I'm sure I cook quite better than five years ago, but I didn't keep a piece to compare it to what I cooked yesterday.

The surprise doesn't come from the difference between how we coded before and how we do now; we expect to code better than what we remember. However, we don't expect so much difference between what we remember and what we actually did.

That's because one of the main things we learn with time and which makes us better programmers is to detect bad code.

Then, we gradually stop programming and start checking for wrong code to ask a programmer to review certain parts. After a while we don't even read the code and simply correct the design. A while later, we just review the person who will review the design.

And all that time, we can read our old code, full of now obvious mistakes and shaped to loosely fit a long forgotten and never written design.

How many changes would writers do if they could rewrite their old novels. How many changes would film directors do if they... wait... bladewhat?

Re:Getting better.

[Ihlosi]

How many changes would writers do if they could rewrite their old novels.

Actually, from good writers you'll get novels that have been re-written several times before they are published.

Re:Getting better.

[matfud]

Yes, if you can look back at an old project and still think its good then you haven't learned much since you did it. Hopefuly there will be little nuggets in there that still please you but over all you should have learned from your mistakes (and you will have made them).

matfud

Why yes, I am a pessimist.

trying to do that were I am

[Anonymous Coward]

I'm trying to do that where I am and there's resistance from the technical directory and team leader, though most of the rest of the company, including the managing director wants us to go the way of standards and best practices.

We write and support a financial application, it's poorly designed (which has lost us customers), buggy (which isn't good for any application let alone a financial one), written in several different languages and is slow and almost impossible to extend. Not surprisingly most of the site and supporting software were written by the technical directory and team leader.

It's not like I'm trying to introduce the world either, only good coding conversions, code review, sign off and tickets for faults/ enhancements, migrating things to one language and most importantly when we write something new don't repeat the mistakes of the past. All this seems impossible since there both too stubborn despite what everyone else says, it was a major headache just to get them doing something as simple as putting sensible comments into their checkins.

Obviously posting anon.

More Design

[Loophole64]

Often times you can avoid a lot of this headache by spending more time in design. If you can flush the project out in some detail during design, and include the customer, more of those changes will be included in the original design before you ever start to code. Unfortunately, others in your organization will often feel like design time is wasted time. You have to be steadfast in your will to spend time in the design phase.

Re:More Design

[Sgt.Modulus]

I know a few people who also feel that design is a wasted practice. I feel otherwise. I feel that design is the crucial phase in creating a program. Coding comes second when you put it all together. For me if I design a program I can see the larger picture of how it goes together. I have no job experience coding but thats what I think and I may be wrong. I think the exception to design time may be Creating smaller programs. Am I wrong?

Re:More Design

[0xdeadbeef]

Design time is wasted time. People don't know what they want, and they won't make meaningful decisions until they have something running in their hands.

Re:More Design

[bunratty]

There are some projects I'd like to flush out, but in the end I usually concede and flesh them out.

Re:More Design

[Oligonicella]

No kidding! For Christ's sake, where have these sloppy writers been for the last forty years? It's not like quality coding techniques are anything new. Client interviews with textual/graphic feedback and an ongoing demonstration combined with clean code written for the next person who will look at it; been doing that since the afore mentioned Apple times as well.

The continuous feedback of easily understood information as to what the design is and where you are goes a long way to keep the client from becoming concerned and thinking it's a waste. It's actually a method for speeding things up towards a positive end.

Re:More Design

[Foolicious]

Often times you can avoid a lot of this headache by spending more time in design.

Theoretically speaking, yes. Practically speaking, no. In fact, no no no no no no no. I've found that more time in the design phase means less time in the actually-doing-stuff and fighting-about-scope-creep and why-have-we-only-1-day-for-testing-and-bug-fixes? and you-didn't-ask-for-that-yes-I-did-no-you-didn't-yes-I-did-then-show-me-where-it-is-in-the-requirements phases.

You're 100% right that better design usually allows for better code; however, when you're in the real world where your actual work is interrupted every 2 or 3 hours by "status" meetings or calls from a "project manager" or some kind of "business analyst" or whatever asking if something is done, and your clients only care about it working just then and there so they can meet THEIR client's deadline (so they can then meet THEIR clients' deadlines and so and so forth), well, then you just get the project done, knowing full well that your questionable code is screwing yourself or someone like you over in the future.

You really have no choice. Principles, aside from the deeply held moral ones, don't carry much weight, especially if you work at a larger company. Calling for standards is all good and well -- until my fat, white (sometimes pimply) butt is on the line. Then I just get it done. I'd rather I get another paycheck than piss clients off and have 10 meetings (cutting into even more of my time) talking about how to implement coding standards that will, for all intents and purposes, never actually be implemented, even after we've decided to implement them!

Re:More Design

[MartinG]

I don't think I have disagreed more strongly with anything I have ever read on slashdot.

If there's one lesson I have learned in my time as software developer (and designer) it is this:

You will not get everything right first time, no matter how much time you spend designing it. You will discover lots of thinks you didn't (and often couldn't) predict, while you are doing the development.

The solution to this is less initial design, and accepting they things will change. You then have more time to change things later based on what you learn during development.

What you seem to advocate is called "waterfall development" and was discredited as a software development methodology over twenty years ago. Despite this, many are still using it, and as a result having software developed is still very expensive and frequently takes longer than predicted.

Re:More Design

[zeroduck]

If the customer doesn't know what they want, why should you write a single line of code? Unless you're on a time and materials deal, this is the first sign that the project is going to be a black hole.

Never underestimate what a good requirements document and design can do.

Re:More Design

[MartinG]

You do have a choice.

What you said sounds like something I would have said a few years ago. Nowadays I simply refuse to be rushed when developing important code. As a result I have a reputation (whether deserved or not) of being one of the better coders amongst us. Managers now come to me for solutions to their difficult problems and are coming to respect the fact that I'm honest about my estimates on work, and although I might take longer than some others, the code doesn't come back to be fixed half a dozen times and make the project even later.

If you are good enough and you company values you, use your position as a lever to get things done better.

Re:More Design

[computational super]

Well, ok, but... how do you "design" without coding? I spent many, many years studying the "rational unified process", wherein one was supposed to make lots of use case diagrams (which the customer would sign off on), from which you would create lots of static structure diagrams (the part of UML that everybody's most familiar with), which programmers could discuss and agree upon, from which you would then create lots of sequence interaction diagrams and from there, finally, the code.

Of course, the Rational people didn't want to admit they'd reinvented the waterfall method, so they *claimed* that this was supposed to be an iterative process - so you were supposed to *then* go back and modify your use case diagrams, which would trigger modifications in your structure diagrams, and then your sequence diagrams, and finally modifications in your code... so, after only a few short decades, you might have a functioning product.

The thing is - I know what you mean. The "design time" is the "figuring out what the hell they're trying to get me to program" time. Unfortunately, without some direction, that ends up being wasted time (as in, you can't go back and justify that time later).

Re:More Design

[0xdeadbeef]

Never underestimate how quickly both of those can change.

I'm not saying one should never devote effort into design. Quite the opposite, actually. It's because careful design is so important that you want to do the cheap and easy part first - writing code. A prototype will save you many headaches later on.

Re:More Design

[zeroduck]

The customer, then, must understand that changing the original requirements will move the schedule out and affect the price of the project.

ECOs aren't cheap, so get your scope right before you commit a lot of resources to a project.

Re:More Design

[Bastard of Subhumani]

Ever wondered why medicine, engineering and law are considered professions, but software development isn't?

The answer is people like you.

Re:More Design

[Tim Browse]

Or as the saying goes:

"I'll start coding - you find out what they want."

Re:More Design

[Tim Browse]

"We try to solve the problem by rushing through the design process so that enough time is left at the end of the project to uncover the errors that were made because we rushed through the design process."

-- Glenford Myers

Re:More Design

[famebait]

Naah. Sure, you need a good design, but you also need sound engineering practices while you're coding. From the problems he describes, I would guess he either has a bit to learn there, or is finding out the hard way how skipping the good advice doesn't pay off for long.

Re:More Design

[Foolicious]

Ever wondered why medicine, engineering and law are considered professions, but software development isn't?

The answer is people like you. Actually, the answer(s) could be a lot of things. But that wouldn't be a witty enough comment to post on slashdot, now would it? If you view yourself as some high-and-mighty, grand and most professional of programmers, then that's fantastic and I, in all seriousness, respect that. But to blame the fact that people don't respect you or your job (profession) as much as you'd like on the fact that I work at an imperfect company, amongst imperfect people and am myself imperfect, is silly. The reason (or one reason) those are viewed as "professions" is because they generally require more advanced degrees, which a programmer does not require. If you believe programmers should be required to have MBAs, MCSs, or Ph.Ds, and that having those degrees somehow actually improves actual work performance one iota, then you live in an alternate plane of reality. Seriously.

Re:More Design

[Foolicious]

You do have a choice.

If you are good enough and you company values you, use your position as a lever to get things done better.
I appreciate your response and practical look at things. You could have called me a retard or "part of the problem", but you actually responded with some practical advice. I agree that you can use your leverage to promote proper methods and approaches to getting tasks done, but you have to choose your battles carefully. Being careful can lead you to being viewed as a master resource; however, it can also lead you to being viewed as the "NO" guy that doesn't really ever want to actually do anything and adds just as little value as the sloppy coder does. A lot is also dependent on managers, as you've said. Apparently, you have some managers that are willing to look at things from a realistic, risk-reward perspective. Not all managers are like that -- especially if it's not only your butt on the line, but theirs!

You have to communicate

[MosesJones]

Getting good IT practices is about establishing a business professionalism in IT that is respected. This means that you have to explain to the business what "good" looks like, you have to understand the business drivers so you can put your challenges into that context and you have to talk to the business in terms it understands.

All too often IT folks bitch and moan about coding, testing, requirements, design time or whatever and how its all the fault of the business. This is victim mentality IT, the way to change it is to actually work out what "good" would be for the business and then work with them to deliver it.

This means the most important coding skill in successful IT departments is the ability to communicate.

Re:You have to communicate

[alan_dershowitz]

We are still in the infancy of the profession of software development. We have a rough set of processes that increase the likelihood of ending up with working, reliable software. What we don't have is the respect that comes from professional recognition. So if you are in a roundabout way saying we need to start forming some sort of a professional guild to force the issue of software development quality, then I agree.

Customers often WRONG

[pjt48108]

The customer is not always right.

Otherwise, it would be the other way around, and THEY would be serving YOU.

AS you might guess, I hated retail.

Re:Customers often WRONG

[Anonymous Coward]

The customer may not always be right but the customer is NEVER wrong - the privlege pf the paymaster

Re:Customers often WRONG

[Anonymous Coward]

...unless you believe in "firing" problematic customers/clients.

We have done so, on occasion. Not in a spiteful sense, and it's certainly something we consider degenerate, but sometimes we have to let clients go--let them move on to other vendors because we aren't a good fit for their needs/expectations.

In the process right now.

[timmarhy]

We've established naming conventions and guide lines everyone seems to be sticking to. the real test will be if they stick to it while i'm away on another project.

I think lack of direction and leadership is why projects drift. hence why many OSS projects have woeful code, because they are hobbies and lack a firm direction.

Happy with mine

[Anonymous Coward]

I'm happy with my code. It's beautiful, modular, fast, maintainable, portable and basic tasks take me only a few weeks.

Re:Happy with mine

[PortHaven]

How do you deal with the situation where fairly complex modifications are needed within 1-2 days.

Yeah...welcome to the world of many programmers...

(ie: where entire workflows are left out of the design model and not even mention by the customer, the customer then exclaims that they are of the utmost necessity and refuses to use or pay for the software until implemented, your boss asks you how long it would take to get it done. You say a week or so. He asks if you can please have something done by Friday. It's of course 4pm Tuesday.)

Re:Happy with mine

[Anonymous Coward]

me too

thoughts

[Anonymous Coward]

I'm also not particularly proud of my code, but to some extent I feel that I've been limited by the environment I've been placed. Where I've worked for the past few months, I've developed classes to move away from our four-year old database libraries, including database abstraction (instead of continuous reams of SQL), along with simple things like fixing SQL injection bugs (no, not saying who I work for). So while I'm proud of these little bits and pieces, I know that the large majority of the code base is still being developed in a fairly archaic way (and it's embarrassing), because the culture tends to ignore best practices - so I'm mostly developing better systems for myself. I'm leaving the company in a couple of weeks, heading home - and I know for a fact that most everything I've developed will simply slip away into the sands, because no-one has really paid any attention.

It's depressing. I think one of the only ways to keep your code fresh and maintainable is to have complete control over your code base - whether that be on a personal development level, or by having a good IT manger who's actually good at defining your class specs, along with pre and post conditions - and to completely remove customers from the equation, of course (even OSS falls under this banner, because you're not really obliged to keep anyone particularly happy).

wise man says

[wwmedia]

one learns from his mistakes or else ...

The virtue of constraint, and other musings...

[Max Romantschuk]

I seem to find that trying to code more slowly than I could helps a lot. I'm not the most efficient coder there is, but I tend to produce less bugs and have more time to make better design decisions when I slow myself down.

I've had several jobs where I've found that although management never seems to approve of a slower process in itself, they do begin to see the values once they notice that my code tends to be less buggy than that of my peer programmers.

As for turning around bad practices... That's always hard. Culture is a tricky thing. But it helps to use analogies, lots of analogies! System grown too large with too many kludges? Compare to building a skyscraper on the foundations of a cottage. Management wants to speed up a project by senselessly adding more people? Compare to: "One woman can make one baby in nine months. Two women can make two babies in nine months, but two women can't make one baby in four and a half months..."

Be creative, be thorough, and be proud of your work. Always try to make the next iteration better, but also remember that sometime meeting the deadline is all that counts.

My two cents, I guess...

Re:The virtue of constraint, and other musings...

[envelope]

meeting the deadline is all that counts.

That's pretty much all that counts where I work.

I have a lot of complaints with my own code, but I don't have time to fix much. There's always another project in the pipeline, and management doesn't understand the need for maintenance. The boss thinks that because he says "we do it right the first time", that that actually happens.

Re:The virtue of constraint, and other musings...

[PortHaven]

"Compare to building a skyscraper on the foundations of a cottage. Management wants to speed up a project by senselessly adding more people?"

Goodness gracious, I wish my old job did that. We lost one of the other lead developers. Did they rehire anyone? Nope...

So it was down to one full time programmer (me). I found a new job and continued working part time (1/4 developer). Now I am gone... *shrug*

At first I felt bad, but it'd been 6 months. Some action should have been taken.

Re:The virtue of constraint, and other musings...

[Anonymous Coward]

It is nice to have NASA quality code - but in the real world we are constrained by time and money.

I myself have written projects which make me quiver when I have to maintain the codebase - but I appease myself by remembering the original constraints I was under at the time or authoring.

I find that the pressure of "outsourcing" for $1400 per month vs. my usual rate - means that to be competitive I have to cut corners some of the time - I try to ensure through testing however that the flakyness behined the scenes - or at the code level seeps through as little as possible to the user interface...

Re:The virtue of constraint, and other musings...

[Anonymous Coward]

The boss thinks that because he says "we do it right the first time" Mmm, you've got to get your boss into the mindset that the first draft of code is always tossed and re-written. I think if non-technical managers/colleagues understood that code writing is very similar to actual writing..with drafts, re-writes, edits, etc they would be more sympathetic and probably understand the process better. After all, you would never submit a paper when you were in school that was the first draft.

Re:The virtue of constraint, and other musings...

[Anonymous Coward]

I seem to find that trying to code more slowly than I could helps a lot. I'm not the most efficient coder there is, but I tend to produce less bugs and have more time to make better design decisions when I slow myself down.

There's one more upside to this. If you slack a little (and don't get caught doing it) project managers starts to give you more time to accomplish your tasks (if you don't get fired). This way you have extra time at the end of the project to polish the code, fix bugs and so on which you normally wouldn't have.

Another thing. Sometimes (read: all the time) our project managers keeps pushing and pushing coders to write more and more code and after a couple of weeks of intensive coding at least I start to break down and the amount of bugs starts to rise because I'm too tired to think what I'm doing. By slowing down every now and then I can get at least some space to breath. Usually this leads to better code and less bugs.

Posting anomously for obvious reasons ;)

Re:The virtue of constraint, and other musings...

[prelelat]

When I have more time to code I have a lot more scrap paper that I burn through. I like to plan out everything on paper first it helps me to think for some reason. But when your given less time to produce something, planning(at least in my case) unfortunately takes a hit and my code does as well.

Of course there are always time when you look back and think why did I do it that way, it seems such a waste. I haven't programmed in awhile though. I miss it dearly.

Re:The virtue of constraint, and other musings...

[Anonymous Coward]

oh shit an analogy guy... stay away from my desk!!!!

Apples/Oranges

[ilovegeorgebush]

In programming, there are a million and one ways to do the same thing. There is no right or wrong, only good & bad. I've seen some damn shocking code over the past few years, and I've written my fair share too. It's swings and roundabouts, it's up to you to learn from your mistakes and push yourself as a programmer to better your code quality. Keep in mind that what you right is what people use, and it's the difference between "computers suck" and "hey, that was cool!".

And as the first reply said, someone will always criticise your code. Decent programmers know this and still do their best.

Worse Than Failure

[Rik Sweeney]

No matter what I think of my code, I always know (pray) that it'll never be bad enough to be submitted to Worse Than Failure.

That said, I do revisit code that I'd written a few years back and think "WTF were you thinking?!"

Re:Worse Than Failure

[CastrTroy]

Yes, there is some truly atrocious code out there. However, a lot of it can be accounted for with the fact that the coder just didn't know any better. Most of the time it's some extremely complicated string parsing that could be easily fixed with a few regex's. However, I know a lot of coders who don't even know what regex is, and how much easier it makes your life. I don't know if we should put more blame on companies for hiring people without enough knowledge, or if it's just a problem with "Too much work, Too few good developers". When the choice is either don't get the work done, or get it done, but it might be sloppy, most places choose the latter.

Re:Worse Than Failure

[Anonymous Coward]

Based on my experience, it's almost required that when programmer #B gets hold of programmer #A's code, there's a period of slagging on it, and saying it sucks. I've said the same thing about most all code I've inherited. And in some (not all) cases, I was right. The same has no doubt been said about my code, and I'm sure whoever said it is probably right in some cases too. This is more about how the guy feels about his own code. Thinking your past work sucks is just a part of "growing up", and getting better at what you do. I recently reviewed some code I wrote 5-6 years ago, and the whole thing was a "WTF". I also reviewed some code that I wrote in the last 2 years. I had a few "WTF" moments, although the basic premise/plot seemed like it was pretty good. I wonder: Does that show a progression in skill, or have I just gotten so stupid in the last 2 years that 2-year-old work (which should grate) seems good to me now? It's worth mentioning that the job I had 2 years ago is the last one where I was actually allowed to write new code. Since then, it's been a long sad succession of projects where I inherit code that really does deserve a place on thedailywtf.com. Because of this, I think my skills are going to hell.

Re:Worse Than Failure

[mondoterrifico]

A few years? Sheesh. I've written perl that I have gone back a few weeks later and thought WTF does this do again. I never learn. :)

Unreasonable expectations

[RandoX]

At my last job, the standard response to any request was "Sure, we'll do that, when do you need it?" and it "HAD" to be done whenever the arbitrary date given was. There was no reasonable estimations of time or scheduling given. The desired end product was a moving target, changing daily. Sadly, the department that was most frequently shorted on time was QA. It took as long as it took to write, and when we handed our best (rushed) efforts to QA there simply wasn't enough time for any regression testing. After several buggy releases, patches, and fixes, upper management outsourced the new version. They were in for a shock when every minor spec change required several weeks for reevaluation and extended the delivery date, plus added thousands to the price tag. When I left there they were starting to lay the groundwork to get some actual structure and communications in place. Hope that works out for them.

Always be proud of your code.

[SolitaryMan]

I'd say that you should always be proud of your code and always do your best writing it. I don't mean that your code must be perfect -- nobody is perfect, but if under current time constraints, requirements and all other circumstances you can do better, then do it.

When evaluating your old code you should take circumstances into account to: may be you were in a hurry and "fast" was more important than "good" at the moment -- it's OK, it's a part of a job. Go back and refactor later. Besides, you are making progress as a programmer, aren't you? So, of course your old code may seem as "bad" and "dirty" -- it's OK too, It's just a part of being a *good* programmer and making progress.

Management

[Algorithmnast]

I know that with my own management, they're quite uninterested in quality - and entirely interested in the "schedule". They have a schedule, and want to meet it with our client (we're consultants) no matter what that does to our quality.

Of course, once the code is accepted by the client then by #definition it is good enough and changes to existing code are only possible if we can prove that the existing code is buggy.

Then there's the bizarre requirement that developers use copy/paste whenever possible. It's not as if we get paid by the line, but it seems that some of the senior architect types think that LOC matters. (no jokes please)

Add in management's desire to see as little change to things as possible, we get a very poor heurestic for Hill Climbing as a model of our software development "practices".

Re:Management

[Anonymous Coward]

I once worked with a really cool team (at a not so cool company), and the thing is after a year as I came there, this team of programmers and managers were so in sync with what our clients wanted and how we should write the programs that we started to hit every single deadline, right on time. Quality of code being top-notch and the clients happy as ever. I thought this was the best job ever...

Little did we know that our Executives had a different view on that! They figured that if we keep hitting the deadline with quality programs, then client expectations will rise and that's bad business. We were asked to lower our standard and produce quantity with light-speed instead.

It took a month and we were producing pure garbage...and surely, the team started to dissolve as few could stand producing shit as a living..

This is the way of corporate programming, I'd say.

I stayed with the company but transfered to maintenance. Here, once in a while some new programmer-bloke shows up irritated by some ugly non-functioning patch-work of code. If I'm lucky I say with a smile on my face - that's my code! :-)

Re:Management

[pk-swe]

The Copy/paste whenever policy reminds me of a somewhat recent encounter I had helping another developer debug something.
me: "What is this piece of code supposed to be doing?"
him: "Hmmm...I am not sure. I copied and pasted it from somewhere."

He meant from somewhere else in our code base, but didn't know where, or apparently why.

Be proud of the work, not the code

[PIPBoy3000]

I have a lot of applications that are elegant enough. It may not have perfect validation for every field and not all the GUI bells and whistles, but it does what it's supposed to. I know my share of developers that spend a ton of time making their code elegant and beautiful. In one case, the developer spent so much time making their N-tier application with huge numbers of tables that were normalized to the bajillionth degree that they were finally let go. The goal is to meet the need, not to fulfill some inner desire to create art with lines of code.

Re:Be proud of the work, not the code

[oliderid]

Personnally an elegant code is:

- readable (meaningful variable names & tabulation)
- commented
- pragmatic (using enum, and all)
- basic design (classes and methods should have been designed prior to any coding (at least the biggest par of it). You feel it when you read a code.

For the rest...If a method needs 20 lines or 100...As long as I can understand it, I don't care.

Re:Be proud of the work, not the code

[PinkyDead]

Sorry, no disrespect intended - but that is an awful attitude.

"does what it's supposed to" is a absolute excuse for writing the worst kind of crud. I see stuff every day that does what it's supposed to do, but it is the worst shite going. It does what it is supposed to do very badly, is buggy, extremely slow and is almost impossible to maintain without serious clean up.

Testing is always the first victim of break-neck development and the outcome is predictable.

Of course proper development can be taken to nonsensical level, but your example of the bajillion optimizer is an extreme; the majority of code that is written elegantly is written within the same timescales as non-elegant code, if you honestly measure the total time to delivery. It is well tested, low on bugs and easy to read and maintain.

The problem with a 'meet the need' point of view, is that it is short term gain at the sacrifice of long term cost. The immediate consequence of this is that myopic PHBs see the solution as a body throwing exercise, with more and more individuals all focussed on meeting the short term need. The result is rarely anything but a disaster.

Re:Be proud of the work, not the code

[pmbasehore]

I second that. I know of a developer who had several lines of comments for every bit of code in his project. A 100-line applet was all of a sudden ballooned into a thousand line monstrosity because he thought that all code should be commented.

I'm sorry, but "If blnVariable = True" is hardly complicated code.

If the program does what it was intended to do, and if the customer is happy, then to hell with the code. It works. Mark it "Complete" and move on. Most of us have too much work to do (with bosses breathing down our necks to get it done "on time") to mess with textbook-perfect code.

That's my $0.02 USD.

Re:Be proud of the work, not the code

[famebait]

The goal is to meet the need, not to fulfill some inner desire to create art with lines of code.

That is true. But it is also true that code will usually be read many more times than it is written. So clarrity and structure does pay. Your example sounds more like megalomania: trying to design the universe. It is much more important for the foce to be easy to maintain and alter that for it to be 'perfect' for some fleeting and illusory interval of 'finishedness'. Just don't ever let it slip too far away from 'shippable'.

Re:Be proud of the work, not the code

[curty]

That's fine, you move on. But spare a thought for those of us whose job it is to modify, maintain and otherwise debug your code once you're gone... We will certainly be thinking of you! ;-)

There is hope!

[big ben bullet]

Buzzword alert: Agile!

But seriously: Things like Test-Driven Development (TDD) and even Behavior-Driven Development have proven to be great approaches in software development.

Also, software management methodologies have evolved in a tight interaction between business (customer) and the development team. Take 'Scrum' for example... think 'iterative'.

If your superiors aren't convinced that at least the test driven part is necessary then you should seriously consider getting out of there.

You can still write crap code, but at least that crap code is backed up by a unit test. Otoh, if your test is crap... you _are_ the weakest link: Goodbye!

TIME!

[microTodd]

The answer to your question as to what is holding you back is complicated and multi-faceted. I'm sure you'll receive many interesting answers (and I look forward to reading them...hopefully it'll help me become a better coder).

From a pure Computer Sciency standpoint, remember that no code is ever completely bug-free...its mathematically impossible. Testing does not prove the absence of bugs, it only proves the presence of successful use/test cases.

But the number one thing holing me back is time. When I'm coding on the company's dollar, there's only so much time to spend in design, in writing test cases, in having someone peer review your code. And thus, there's just not enough time to spend doing things in the absolute, 100% correct way. There has to be some compromise.

I suspect that even if I had time, I would run out of mental energy first.

Re:TIME!

[msuarezalvarez]

From a pure Computer Sciency standpoint, remember that no code is ever completely bug-free...its mathematically impossible. Testing does not prove the absence of bugs, it only proves the presence of successful use/test cases.

While that is of course true in an absolute way, for quite a few problem areas---including a big part of the standard programming problems an average programmer will encounter---one can produce verifiably bug free code, assuming you have proper specifications (up to bugs in compilers and such things, of course) Of course, that does not come free nor easily... And good luck getting proper specifications.

Re:TIME!

[Oligonicella]

"...remember that no code is ever completely bug-free..."

What? I've seen and written plenty of code that was 100% bug free. Programming is not math. It uses math, but it's the same mistake of thinking math defines the world. Now, if you're talking about a system or large application, I'll buy in. But even there, you have to speak to the relative impact of the bug. I mean, in terms of pedantry, even a friggin' typo in a message is a bug.

Re:TIME!

[kalidasa]

Actually, programming *is* math. Always; even HelloWorld is math. You just don't really understand what math is. And while it's false to claim that no program can be 100% bug free - you can certainly write a bug-free FSM to do something simple, and maybe even implement it in electronics - all code that's an order of magnitude more complicated than HelloWorld has some bad choices in *somewhere* the high-level code, the compiler that's used to turn it into executable code, or in the instruction set that compiled code runs against that may not lead to logic errors, but do lead to imperfections in execution.

Re:TIME!

[DRobson]

From a pure Computer Sciency standpoint, remember that no code is ever completely bug-free...its mathematically impossible. Testing does not prove the absence of bugs, it only proves the presence of successful use/test cases.

Should checkout formal methods, mathematical tools and processes for designing, building and verifying software and hardware systems. Currently it's only really feasible for small, critical systems but I'm betting it'll grow (I should really keep an eye on the L4.Verified project). Of course with all this you're still at the mercy of your specification, get that wrong and you're back to square one ...

Re:TIME!

[jethroT]

bug-free code mathematically impossible??? What strange sort of mathematics is that.

I can trivially prove that bug-free code exists: The empty program is a bug-free implementation of doing nothing.

Or: By defining that a specific program should do exactly what it does now, that program is absolutely bug-free.

You were probably thinking about the "halting problem" in computer science. There are programs where you can't prove total correctness because you can't prove they ever stop, see wikipedia for an explanation.

Re:TIME!

[ct1972]

Mathematically impossible or statistically unlikely? Can you point to a real mathematical proof of this?

From a pure Computer Sciency standpoint, remember that no code is ever completely bug-free...its mathematically impossible. Testing does not prove the absence of bugs, it only proves the presence of successful use/test cases.

I am not a computer scientest, but I am a mathematician, who also writes a lot of code. I can't imagine any basis for such a proof, and certainly, if all you are saying here is that it is impossible to prove the non existence of bugs, that certainly doesn't equate to the impossibility of the existence of bug free code.

In any case, is there even a proof that a system cannot be proved to be bug free. I suppose that Godel's incompleteness theorem may apply eventually, but presumably simple systems can be proved to be bug free.

Re:TIME!

[Anonymous Coward]

100% bug free in which language? That language has no bugs? I wouldn't say it's mathematically impossible, but I would say that it might not be feasible in most modern environments. For instance lets say I write a program and my code is 100% bug free even if it's only 20 lines. There are countless bugs that may still be encountered. OS bugs can happen at all levels which can plague your program. If I write a program in Perl, then Perl may have bugs, or maybe the Imagemagick library, or maybe the png library, etc. When you drill down with modern programing it's probably near impossible not to have the possibility of tripping over something, even if the chances of doing so is very small (in a perfect program).

Re:TIME!

[snark23]

A type system is a theorem, and a [correctly typed] program is a proof. This is Curry-Howard isomorphism.

Thus, proving properties about a program can be done as a mathematical proof, and Godel applies in a more general sense in exactly the same way it applies to all mathematical proofs.

So it is possible to prove that a program doesn't have any bugs, but you have to either be able to define what a bug is (e.g. "access beyond array bounds"), or define what it isn't ("a correct program shall always free memory that it's allocated"). Ultimately I suspect that proving a program is 100% bug-free is just as hard as writing the correct program (for non-trivial programs); but I'm not sure about that. Alternately, you may define some behavior as a "bug" that is not possible to prove in the general case, e.g. "this program halts", in which case you're out of luck.

Of course, this demands that you know exactly how your code will execute. That requires either a language with complete semantics (SML? Haskell?), or a really profound understanding of the compiler and runtime system (because the specifications of most languages, like C, do not completely define their computations). This is why this sort of thing isn't done very often.

There are some systems/languages which guarantee certain properties... this is "proof-carrying code", and is only used right now on some mission-critical systems... but may get more popular some day, as it allows you to trust chunks of anonymous code.

Re:TIME!

[Tim Browse]

But even there, you have to speak to the relative impact of the bug. I mean, in terms of pedantry, even a friggin' typo in a message is a bug.

So your claim to writing plenty of 100% bug free code is dependent on your ability to redefine the term 'bug' as you see fit?

Hmm...

Re:TIME!

[Maximum Prophet]

remember that no code is ever completely bug-free

Check out /bin/true and /bin/false. I'd post the code here but on Solaris it's "UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T"

/bin/true is just comments. The shell exists true by default. /bin/false is just "exit 255".

Note that both are version 1.6. The first 5 versions must have had subtle bugs that had to be worked out.

Lost out

[gaou]

"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Edsger Dijkstra

Sorry mate, there is no hope :)

Re:Lost out

[Anonymous Coward]

This is the most stupid quote I've ever seen on Slashdot.

At college, all of the enthusiastic students could already code fairly well having learnt BASIC on their Amigas or BBCs; we were already so far ahead of the class that none of the others had a hope of competing.

At Uni there were a few poor PC users who were ahead of us in their understanding of C at the start of the year but, by the end of the year, whereas we'd all picked up C, assembly and Ada (God knows why), they were still struggling with the different styles of programming.

Decent versions of BASIC are basic, linear and allow the programmer to develop a programming style that suits himself. The BASIC programmer gets a good elementary understanding of how the computer works with a nice lead in to the more advanced issues of pointers, etc. Typical users of Amigas and BBCs have played with graphics, sound, games and have already hacked on other people's code (magazine's, etc) by the time they get to Uni. These basic, underlying skills support them throughout their programming career, allowing them to pick up new languages and work with their idiosyncrasies instead of constantly battling them.

Re:Lost out

[bhaak1]

Just for the record: AmigaBASIC was my first real programming language (LOGO on paper doesn't count).

That you don't know this quote (it's from 1975 BTW) and have been to the university just shows how much CS is a science without respect for its history.

That you don't have heard of Edsger W. Dijkstra is shame.
http://en.wikipedia.org/wiki/Edsger_W._Dijkstra

Tell me, do you consider the GOTO command harmful?

"Have any developers here successfully lobbied...

[Nursie]

...their company to stop or cut back on 'cowboy coding' and adopt best practices?"

I didn't need to, I work for a competent company that aren't going to compromise the quality of their product on the whims of a single customer.

I also happen to think my code's great, thankyou very much. I couldn't imagine going through life thinking my code was awful. I'd lose the will to live and find another career.

mod parent up

[Anonymous Coward]

realizing your old code is crap means you are improving. if you have less than 10 years experience with a language, chances are in 5 years you will think what you write now is crap too.

Re:mod parent up

[digitig]

realizing your old code is crap means you are improving. if you have less than 10 years experience with a language, chances are in 5 years you will think what you write now is crap too. Agreed wholeheartedly. Now, there's probably nothing that a junior programmer can do to stop projects drifting (heck, even the gurus struggle with that!) and they probably don't have the influence to change the entire development culture, but they can do the Right Thing with their own code. Always consider in what circumstances it's legitimate for a piece of code to be invoked, and document it. Consider what it should do in other circumstances, and document it. Consider how it should react if it can't do what it's supposed to, and document it. Try to double guess which requirements are stable, and which are likely to change, and design to make likely changes easy. (I'm assuming here that the customer can't tell you anything useful about those things -- if they can then you can do better still). And when you get it wrong, think about why you got it wrong, and see whether you can learn how to do better next time. Just remember that getting it wrong doesn't just mean failing to anticipate changes, it includes over-engineering the code to account for changes that were never likely.

Re:mod parent up

[SageMusings]

Of course 10-years experience with a language is also a red flag in today's market.

It means:
(a) You are too old. We can hire 10 more like you for a third the cost straight out of school.
(b) You want too much money and are probably aware workers have some limited rights. We prefer cheaper sheep.
(c) You haven't spent enough time playing with the latest language "du jour" and are no longer flexible enough for the organization.
(d) If you're not in management by this time, you're not valuable enough to the organization.

At least 80% of the people I have worked with have been coding for less than 3 - 4 years out of college. I know there are old "salts" out there somewhere with great amassed knowledge. I just haven't found them yet.

Not enough time

[paranoid.android]

"If so, then what is holding you back from realizing your full potential?"

Time.

I'm swamped with numerous projects. If I had the time, I'd go back and fix the kludgey spaghetti-code nightmares that I've conjured up, but since they work for their intended purposes, other projects that are more important to my management-types get priority.

Work for engineers not software companies

[Hektor_Troy]

The best code I've ever had the pleasure of working on, was made when I worked for an actual engineering company. Not software engineering, but engineers that build physical stuff.

They understand the need for excelent documentation, rock solid requirements and that you don't get halfway in a project and change its direction (ie, "sure, the Golden Gate is halfway done, but we'd actually like it to go from Lime Point and meet up with the Bay Bridge around Treasure Island Road"). They understand that some things take half the time to do but are four times as expensive to maintain, and they prefer quality over quantity.

Least the ones I worked with

Re:Work for engineers not software companies

[Anonymous Coward]

If I had a slashdot account and some karma I would mod you up insightful.

Real engineers view programming as an "engineering process". Programmers these (at least the ones I talk to) constantly refer to what they do as an art. While, to some degree, that may be true, when you stop viewing software development as an engineering process you lose discipline.

Developers tend to strike out on their own, because "they know the right way". Code commenting becomes over/under done. The list goes on.

I started out my career as a developer for more "traditional software" (interface design, productivity apps etc), and after a few years ended up working with real engineers on mission critical systems(embedded systems, robotics etc). The quality of code in the past 5 years that my colleagues and I have produced far exceed that of my former years in almost every way.

Commercial software development should not be viewed and treated as an artform. If one is at home coding in their spare time, call it what you want. But if you want to build software in a commercial and/or mission critical setting, then it should be treated as an excercise in engineering.

In a word?

[Zebra_X]

Yes.

Do some open-source coding to feel clean again.

[Dr. Manhattan]

Eric Raymond wrote, in "The Art of Unix Programming": "The combination of threads, remote-procedure-call interfaces, and heavyweight object-oriented design is especially dangerous... if you are ever invited onto a project that is supposed to feature all three, fleeing in terror might well be an appropriate reaction."

The product I work on at work features all three. It can be 'interesting' to maintain sometimes. That being said, it's frequently possible to rewrite sections and management sometimes listens to the programmer types and has let us restructure things sometimes. For example, we've mostly gotten rid of the RPC stuff.

When I want to satisfy my urge to work on good, clean code, I do some open-source work. Open-source tends to have that, because nothing else tends to work for very long.

Re:Do some open-source coding to feel clean again.

[johannesg]

Sorry for being a bit slow today, but what in particular causes problems with that combination of factors? And what would he consider to be "heavyweight OO design"?

Re:Do some open-source coding to feel clean again.

[Dr. Manhattan]

Well, you could read the section where the quote appears, and the previous section where some of the problems are laid out.

MODS

[TapeCutter]

This GP is obviously speaking from many years of experience, and not just in IT.

Deadlines

[Martian_Kyo]

usually kill projects

The only thing i can advise, is have a small personal project aside. Yes program on your own (or join an interesting Open source project), when the project will be finished is not as important as using all the proper practices while doing it. That means flexible design, patterns, comments and such. Show yourself at home that given time, you can actually make good code.

Then maybe after a while some of those good habits will seep into your daily work. Very few companies will care about the code, they usually only care about the deadlines.

For me, good code is like good math

[AccUser]

How often have you solved a mathematical problem, and the whole solution has looked and felt right, not just the answer? I have always enjoyed mathematics for this reason, and take the same approach in the way I write code. To me, my code just looks and feels right.

I realise that others don't feel the same about my code. I have often been criticised for not enough code documentation (but then, that usually means that someone can't understand code, rather than just not understanding my code), and I have often been criticised for not using temporary variables, but I am rarely criticised for delivering unmaintainable code that doesn't work.

Re:For me, good code is like good math

[Anonymous Coward]

"but then, that usually means that someone can't understand code, rather than just not understanding my code"

Oh that's ok so. If it's been said to you 'often', they're probably right.

Re:For me, good code is like good math

[Jamesie]

I have often been criticised for not enough code documentation (but then, that usually means that someone can't understand code, rather than just not understanding my code)

I bet that they understand code, it'll be your code that's the problem. I've heard plenty of people claim that their code is self documenting but when you read it takes ages to understand, all for the sake of a few well thought out comments.

All Code Sucks...

[iBod]

...to somebody, for some reason.

There is no Holy Grail of code.

What is good coding style to me, may be anathema to you.

Ok, there is utterly shit code (which probably accounts for a fair proportion of all code if my life experience is anything to go by), then there is 'run of the mill' code, then sometimes rare glimpses of 'great' code.

Great code for me is when you see it and understand the programmers intention, and you think: a) I would have done it that way, or more likely b) if I was smarter I would have done it that way. You learn from great code, if you're already a good coder.

I think the greatest obstacle to 'great' code is 'language fascism'. Some languages are better than others, that's true, but they way some people carry on you'd think it was only possible to write 'great' code in their language of choice. This behavior is generally exhibited by those that can code in one (or at most two) languages only.

I'm generally proud of my code and am happy for others to scrutinize it. All that means is that I spent the time to make it as good as I could withing the prevailing time/cost constraints.

I used to write a lot of assembler. Some of my colleagues used to think it was cool to use obscure instructions, in unintended ways, just to show how 'cool' they were at flipping the registers. I never subscribed to this idea and always used 2 or 3 common instructions instead of one 'neat' instruction. Performance never seemed to suffer and maintenance programmers were eternally grateful.

Re:All Code Sucks...

[Lars Clausen]

I think the greatest obstacle to 'great' code is 'language fascism'. Some languages are better than others, that's true, but they way some people carry on you'd think it was only possible to write 'great' code in their language of choice. This behavior is generally exhibited by those that can code in one (or at most two) languages only. Having used over 2^4 programming languages, I frequently get the 'this could be done more nicely in X' feeling. In particular, my Java programs could benefit from having Scheme-like macros that allows actual extension of the language.

-Lars

Re:All Code Sucks...

[iBod]

Yes Lars, I know what you mean.

It's good to bring the 'mind set' of one language to another. While it's not always practical, it's often useful to imagine how you could reproduce one neat feature of a particular language or environment within the constraints of another.

I think that's the best and most natural way for languages be extended and improved.

Good that you know 2^4 languages! I think the more programming languages you know, the more you realize there is no perfect language. Everything is a compromise.

Re:All Code Sucks...

[jgrahn]

It's good to bring the 'mind set' of one language to another. While it's not always practical, it's often useful to imagine how you could reproduce one neat feature of a particular language or environment within the constraints of another.

It's not so good when you're the maintainer, and the previous programmer went: "Oh, I don't like/understand C++; I'll just pretend it's Java/C/Perl!" You need one mind set - the native one - for every language you use, or you're going to write unmaintainable code.

Of course, knowing another language well and being able to reflect on the similarities and differences is a good thing.

Re:All Code Sucks...

[Anonymous Coward]

Great code for me is when you see it and understand the programmers intention, and you think: a) I would have done it that way, or more likely b) if I was smarter I would have done it that way.

The problem is that programmers tend to be so nitpicky that they will slam others' code for its variable names and placement of curly braces while completely ignoring the fact that it's thoroughly correct and efficient. It helps give them a feeling of superiority, but, unfortunately, it tends to be detrimental to the overall effort of software development.

Code is communication

[Dystopian Rebel]

After a long time in the software industry, I came to realize that Code Is Communication.

By far the largest part of the lifespan of any code is Maintenance. Code has to be intelligible. Not just through commenting, but in every construct and usage.

Think about effective communication. The effort to be clear will improve what you are doing. It will also make your mistakes evident so you can correct them.

Re:Code is communication

[Khelder]

A professor I had early on in college (Randy Pausch) summarized it this way:

Think of programming not as a way of telling the computer what to do, but as a way of telling someone else what you want the computer to do.

If you think about your real audience as another person and not just the test suite (assuming you're not still thinking of it as the compiler), I think it really helps write maintainable code.

Re:Code is communication

[TheLink]

For me code is decision compression.

Now the trick is to know what things might likely be changed in the future and design things accordingly so that those bits can be more easily changed ( or not need to be changed at all - no changes needed to code- just set this config var :) ).

Re:Code is communication

[SurturZ]

True! I rigorously comment and document my code not for the benefit of other programmers, but for the benefit of myself in six months time .

Re:Code is communication

[tomatoguy]

I am not a pro coder at all, but I have worked with some and have absorbed their best practices to make myself a passable coder generally, and pretty darned good when pressed.

One of the best lessons I learned from the 2 most-influential mentors in my coding life is the power of legibility. Use whitespace, indenting and layout to make things more exposed. Take advantage of the fixed-width nature of a code editor to make nice blocks that attract and keep continuity and pattern-ness.

My greatest peeve is code that is single-spaced with goofy, or no indenting. If I see a mash of text I am already wanting to go elsewhere because it's not even fun/interesting to look at, nevermind figure out.

Code is a killer

[Anonymous Coward]

Code is the killer. The less if it you have the better off you are. You can reduce code by a good architecture and experience.

Bad code is usually a result of either inexperience or through a lack of time (rushed project timelines = bad hacks).

Recognising that you've produced some bad code is the first step to absolution. Try understand why you produced bad code and improve yourself. Rushed project timelines can force you to code badly however maybe you need to be more skilled/effective at a wider range of frameworks allowing you to do more in the time you are given.

Takes a group to judge an individual

[eebra82]

Gather around me kids, for I am sitting here in my 18th century rocker to tell you a story about a programmer.. A good programmer..

I used to work for a small-sized IT business; a popular community that housed some 130,000 members. It began with the loss of a fellow employee who had basically coded 99% of everything on the site. To that date, everything had worked fine. We had some issues every now and then, but a backup system helped us from getting hammered if anything bad happened.

We never worried too much about him leaving because, for starters, I had some experience with the code/system. In addition, the now departed programmer had left a comprehensive list of features and explanations of his system that would help any programmer (that would replace him) to get around any tricky problems that would/could occur.

Unfortunately, I won't go into what type of business this was, but let's just say that it's not typical programming skills. When I began looking for his replacement, I realized how hard it was to get someone with adequate skills and all the knowhow that was required besides the actual programming. As we were on a tight budget, it was important for us to find that one guy who didn't expect a zillion dollar salary. Typically, that would be someone who shares our interests, a recent graduate who knows his ways around programming.

Eventually I found one guy who claimed to be all that we wanted. After a month, it turned out that the guy was more and more frustrated over how things worked at the company. He disliked about everything about the code and spent most of the time cursing. At this point, I started to believe that our entire code sucked.

Roughly a month later, we decided to rebuild "everything" so that he could have his ways around the code. Since we only had one programmer, I had to comply because it was an important role in the company. My limited coding skills provided no extra help in evaluating our current code, so I trusted this guy since he seemed to be very thorough and experienced. Also, I was promised it would take no longer than one month to do all this.

What a fool I was. If it ain't broken, don't fix it. I should have known, but a company on a tight budget and no one else with good programming skills forced us into this move. Turns out, our super experienced programmer needed not one month, but two, three, four, five, six and seven months to complete his task. By then, he had reprogrammed almost everything and merged some of it with the old code. We waited for the relaunch of our software with great anticipation. Three! Two! One! Go! Oh crap, everything f*cked up.

Following the launch of our new software, we had months and months of trial and error problems. Members were complaining and nothing went in the right direction. Eventually, we were essentially bankrupt and had to let the superb programmer go. The guy who had left us with a huge mess.

When I read this Slashdot story, I had a smile on my face because I learned that a programmer can only know that his code is perfect by the response of many other programmers who can view his code (i.e. open source). Some programmers seem to think their code is perfect and that occurring bugs are caused by impossible-to-foresee problems. The point of my story is that if you truly want to know if you are a good programmer, you must let a lot of programmers decide that for you. Unless your name starts with J and ends with ohn Carmack, of course.

Re:Takes a group to judge an individual

[oliverthered]

So what your saying is that if you had more programmers they should each look over each others code once in a while (or even preferable all the time). Sounds a lot like Paired programming or code review to me. (+ you get the benefits that when one person leaves the company anyone else should be able to pick up)

Re:Takes a group to judge an individual

[Anonymous Coward]

That's why, if your code "sucks" (or someone makes you believe it sucks), you should always insist that your codebase is improved *incrementally*.
Make sure your code keeps running well all along the path of a rewrite, and introduce new (or change existing) abstractions one by one.

Re:Takes a group to judge an individual

[jabjoe]

This sounds familiar, sounds something like what happened at the middleware company I use to work at. New programmers came in, said the old API was shit, started again from scratch. It learnt nothing from the old code, ignored customers, and when we where bought out, our buyer realised after trying to use the new API for probably too long, it was all a mess and killed it. (Not going to say more because I'm not sure what ground I stand on....) But my dad also works in software, and well before this happened to me, he told me about a cycle of code maturing, then new programmers coming in, saying it was all shit ,starting again and it taking years for product to mature again. And round and round it goes.

Re:Takes a group to judge an individual

[ravyne]

In terms of code quality, I wouldn't put Carmack on too much of a pedestal. Performance? Yes, he's quite good with that... but I've heard obtuse, poorly commented code referred to as "Carmackian" on more than a few occasions.

Re:Takes a group to judge an individual

[syousef]

Let me get this straight. You wanted to get an good programmer who knows their way around code, straight out of an undergrad degree. Oh and he better not know what he's worth because you can't afford him. When you finally fooled yourself into thinking you could get a programming genius for a few pennies, you decided to let him loose re-writing your entire code base, didn't test it properly (hint: you didn't have the staff to do it since the guy that writes the code shouldn't be the only one to test it) and then wondered why HE left you with a mess???? You've learnt nothing. You have one person to blame and it's not some guy you picked fresh out of uni. YOU made the mess. The same guy may or may not have learnt under the wing of someone more skilled (granted if he spent his time grumbling, possibly not) but you didn't give him the opportunity to do so. You got greedy. You suffered. He suffered and you're now whining about his inadequacies, and blaming everyone but yourself.

Thank FUCK I don't work for you. Seriously.

It's not just the client

[Dr. Winston O'Boogie]

If you have management that doesn't really understand what programming and programming personalities are all about, you can get internally inconsistent, half-thought out ideas as well as much pressure to do it 'now' instead of 'right'. If your programming team is more junior and easily swayed by the management's idea of software development, then there are no checks and balances and you get rushed out, low-quality code, with a never-ending cycle of quick patches that is ugly, bug-prone and a nightmare to maintain. And that's assuming you have a quality team of junior programmers. Mix in average or below-average programmers and......I shudder.

Yes, I am

[rdrd]

I work with/for some French guys. French people tend to have bright ideas in the most unpleasant moments (#include "irony.h"). Nevertheless, I was able to cope with the requests, and as a technical leader I was able to impose some of the solutions. The result is very neat, and I'm really proud of it.
I will say this: I am convinced that some better solutions exist for some specific problems; I do not agree with some of the imposed constraints. But: measure the quality having in mind time and cost.

So yes, there are nice projects outside.

TCO

[devnullkac]

Saying "no" to the customer is not normally what's called for. Instead, your team must clearly state the total cost of any proposed change. Factoring maintainable quality into cost estimates is an art that an organization must learn if it wants to get asked to do another job after the money for this one runs out (project drift leads to no results leads to unhappy customers, as you well know). When the customer responds with "Well, isn't just as simple as changing X into Y?" then that's when you get to say "no."

Here's a start to better code

[Man_Holmes]

My advice would be to read The Pragmatic Programmer book by Hunt and Thomas. It provides the best blue print I have seen to solving the problem for you.

You may not be able to implement all the changes at once but you will find that you've got more authority than you realize.

You may not even agree with all of it, implement what makes sense and your code will improve. I've found with my friends that the longer you've been coding the more sense that the book makes.


Man Holmes

Unfortunately, yes.

[squiggleslash]

Which means that I tend to get married to design decisions I made and have to deal with the inevitable consequences when what looks graceful programmatically is a nightmare when converted to a UI for the end user.

One of the interesting lessons I took from Mac OS X and GNOME, probably the two best mass market UIs on computers these days, is you can't always orientate your applications towards future expandability, because adding modularity and extendability frequently results in a poorer user experience.

Personal Best Prqctices

[aunchaki]

> Have any developers here successfully lobbied their company to stop or cut back
> on 'cowboy coding' and adopt best practices?

For me, it was a matter of defining my own personal set of Best Practices and sticking to them. Something as simple as standardized variable naming, or consistent formatting. As _I_ set standards for myself, I shared them with fellow coders and we'd come up with an unofficial set of Best Practices. None of these things slowed my coding down or cost the client a cent, but they made all of my code more readable TO ME and helped me to cut-and-paste code (reuse, recycle!).

What's more, it made me feel like I was coding better than I did when I was in my anything-goes, cowboy days. And guess what? I _WAS_ coding better!!

Dude

[PoetDemise]

Guessing from your post, "I enjoy programming and have from a young age (cut my teeth on BASIC on an Apple IIe)." , I am going to assume you are a bit more seasoned as a programmer. Well, one the best things to do is to drop the old code. Java may have been around, but it keep up pretty well. If your code is slow, write cleaner code. Object oriented coding the best way to go. Keep methods short and clean but board and ensure to have overloaders. In today's day in age, code must be very dynamic, static methods are thing of the past. They are still very powerful and good tools but your code should not be based around them. Well I suppose I should get back to code and will do my best to keep my code nice and clean today.

The waterfall model

[Per Abrahamsen]

Which is why the water-fall model is rarely a good match for software development.

And, incidentally, also while outsourcing (especially off-shore outsourcing) software development is rarely leading to success stories.

The difference - Testing

[mach1980]

In our organization we went from spaghetti code to excellent code in under 24 months. The catalyst were the introduction of testers.

They validated our requirement lists and reviewed our system designs. As (us) software coders got the knowledge that their code were in for in-depth testing they started doing proper design work, peer programming and later module testing. Then, with the help of the test team, we started to maintain KPI:s about the process and got better delivery precision of the software.

As the number of bugs dropped we didn't need to patch-and-ship code. Now we release bi-yearly instead of bi-monthly which leaves even more time for QA-work.

Testers doesn't do quality - they are a catalyst to enable quality in each step in the software development process.

That's closed source programming

[Anonymous Coward]

in a shoe box for you. Set deadlines. Always too few programmers. People who don't give a shit about anything except you get the product out and sold. That'd be your boss. Crappy code. Nice wrappings. And marketing department spends 4-7 times more funds than the actual programmers. But hey, don't worry, in a month or two, nobody remembers the project you worked on. And the sad code goes the way of all bits.

Code...

[CFBMoo1]

Two thins I can suggest:

* Keep things small, and by small I mean one procedure or function does one thing small. Don't pack it with extras or this or that. KISS it. Using a language without procedures or functions? Space things out and label blocks of code with comments. If you can break that code up in to seperate files with includes then do so. Test all the peices seperatly.

* Documentation, don't put a one liner up at the top of a block of code and call it a day. Be descriptive, say what happens, what comes from where, whats passed in and whats to be expected in the return. The more you spell it out for someone and yourself down the line the quicker the light bulb will go on when someone or yourself has to review what you did several months or years ago.

Yes

[Average_Joe_Sixpack]

I often use "Programmer: Alan Smithee" in the comment header

Re:Yes

[kalidasa]

I'm guessing most of today's mods don't get the joke.

Yes, yes and yes

[YeeHaW_Jelte]

Yes, I am proud of my code, or maybe not always the code but at least my coding. It's not always possible to create beautiful, well mantainable code. I try to, but sometimes there's just not the time.

Yes, I have convinced my employer to stop allowing cowboy coding practices -- she didn't even realize it was happening. I'm currently head of the programming division of a inhouse IT dept for a large travelagency specialized in cruises ... it's a pretty large department for such a small company, as we write all our inhouse software ourselves and have been for the last 5 years. When I came to work here, the codebase was about that old -- 5 years -- and maybe a two dozen different 'cowboys' had been writing the software resulting in a large heap of steaming shit. They were not centrally coordinated and everyone of them was doing things in his own style either out of laziness of ignorance.

Anyhow, I managed to convince the CEO that there was a problem ... she had no idea that it was a mess, the company being a travel agency and she having very little knowledge of automation herself. I used a difficult coding project (connecting to a GDS, the guys that administer plane reservations, car rental, cruises etc) and a general optimation project ( the application was becoming very slow due to all the bad programming going on ) to build her confidence in me and asked her to put me in charge of code sanity. She did.

I am now trying to reform the bunch of code cowboys that currently works here to a well disciplined programming team ... and I hope I'm succeeding. Gave them code standards to work to, asked them to clean up the code base where they stumbled upon crappy pieces, moved from Visual Source Safe to Subverion (thank god!) and started regular meetings once a week.

The codebase is still very messy at places, but many basics (use of one and only one database class e.g.) have improved very much and I think the people here are happier for it. It's much less frustrating to work on nicely formatted code that doesn't have braindead sections that aren't commented.

To make a long story short, if you're not proud of the code you write, make sure you improve it.

Re:Yes, yes and yes

[Bill_the_Engineer]

Ditto. I also can say yes, yes, and yes. May I add:

First rule I have is that even though I have more than a couple of decades of experience, I am only human and make occasional mistakes. This is why I always have my code reviewed by my colleagues.

Second rule, I have is to not rush the client interview. I lost count on the number of times I witnessed a programmer talk to the client and think he fully understands what is wanted. They must suffer from attention deficit disorder, think the client doesn't know what they want, or worse think they have a better way of doing things and actually believe that the client will fall instantly in love with their "radical" design. Seriously, I seen client interviews last less than 20 minutes. Feature creep and cowboy coding are usually the result of the programmer not understanding the task that the client hired him to do.

Third rule, document the work. Nothing chaps my hide like a programmer who thinks that the more obscured he makes the code the more indispensable he will be. Sadly, they never seem to last past a couple of months and find it hard to get on another project with us...

If I could boil everything down to a single word, it would be RESPECT. Respect your limitations. Respect your client. Respect your colleagues. Respect who may inherit you code.

after 8 years of professional coding...

[w4rl5ck]

I came to the conclusion that you are the only person who is ultimately responsible for the state of the code you write is YOU. Nothing else, no one else.

Project deadlines, crazy customers, chief engineers, thunderstorms, even a Tsumani. It's just you.

Reason:

if you write buggy code, whatever the reason may be, it falls back to you. You will have to fix it, you will be MADE responsible for it. EVERY time. No one asks WHY you did it.

And you don't like it yourself, which is a bad thing. One should LOVE his work, not hate it.

If you force yourself to push everything else into a state that enables YOU to write good/nice/beautiful code, you will gain something. If not, you will suffer. That's about it. It has nothing to do with other people, with companies, with unemployment.

So, get up, and write that good code. Whatever it takes.

Good luck :)

Re:after 8 years of professional coding...

[eggoeater]

Wow, talk about over-simplifying a complex issue.
So basically what you're saying is that if you're in an environment that doesn't allow you to write good code its your fault?
Not everyone can quit a good job just because the IT management has their head up their ass.


I've written plenty of crappy code because of arbitrary deadlines my group had no control over.
In large companies (that aren't tech oriented), the IT department ALWAYS have deadlines
dictated to them by the business unit, not the other way around.

Re:after 8 years of professional coding...

[Lalo Martins]

nn? Who modded this "insightful"? Lay off the booze...

Re:after 8 years of professional coding...

[w4rl5ck]

>So basically what you're saying is that if you're in an environment that doesn't allow you to write good code its your fault?

In a way, yes. Point being, it's not your fault to be forced to do so, but not to CHANGE the situation is the programmers fault.

If a coder always "does as he's told by (stupid) management", and I did that for a few years, because it seems "logical" to do what you are told to, and keeps writing crappy code, because the deadlines can not be kept otherwise, and does this over and over again - getting more and more frustrated, moral down, writing more and more crappy code because all the other crappy code in the project makes it crappy again...

I think it's more or less clear were this leads to.

Of course, one should not lightly quit is job. In fact, I would say, KEEP your job, and work with your superiors/co-workers, and point the problems out in a way THEY will understand.

"Hey, OK, this CAN be ready tomorrow, but it will be buggy, and as WE both know that the customer really wants feature C, D, E and not only A, and the quick hack would need a complete rewrite in 2 month ANYWAY, *you* are going to loose approx. 2 weeks of manpower if we fix this until tomorrow. Definitly. If we do it right, the customer will whine for two days, but be satisfied after those two days, we won't have (that many ;)) bugs, and we won't need a rewrite until 2009. 12 days spare time for that other deadline four weeks ago".

If you *give up*, and say, OK, the world is like that, I HAVE to write crappy code, I personally think it's ultimately YOUR fault, yes.

The world is not static, it can be changed. If you really WANT to write nice code, and push your surroundings, especially with a good group of coder-coworkers, pulling in the same direction, this will ultimately (over time!) lead to a better product, better code, and more fun at work. And if the code written last week is not crappy, it will save your day over and over again. Crappy code *costs* time forever, good code saves time forever and ever.

Of course sometimes crappy code can't be helped. I wrote crappy code the last few weeks, too. We have to. But I always try to avoid it, to push into a direction that leads to a better code. And it simply works. It's about "how much of the code I write is crappy". It should lead to 0% at some time in a very distant future (aka "infinity").

As I do a bit of consulting next to "real" coding work, I have some external experience on how programmers see projects, how the tie-people see projects, and how everything "comes together". Mostly it's about targets and moods between the people, and the "overall spirit". "Just get over with it", or "Hey we could make this COOL".

The Tie-Person wants to finish ASAP, with lowest cost. The programmer wants cool features and lovely code. Both have to talk properly, understand the other one, and work together to finish ASAP *for a great product*.

You clearly see whether people just "code to get finished" or "code because they like their code". And you can see it when you look at the product, at the bug reports, at the UI. It's either "just right", or "crappy".

So:

DON'T WRITE CRAPPY CODE. It's your choice.

This is not a rule. It's more like a ... guideline ;)

Re:after 8 years of professional coding...

[Anonymous Coward]

You will have to fix it, you will be MADE responsible for it. EVERY time.

Akin to saying if someone commits a crime they will be caught and prosecuted every time.

I've come across a lot of buggy code which I didn't create but I was responsible for fixing.

Welcome to the real world

[Anonymous Coward]

"Has anyone convinced their superiors that the customer isn't always right and saying no once in awhile is the best course of action?"

No. Welcome to the real world. Feature creep is unstoppable.

Yes.

[Anonymous Coward]

At my work, we don't do cowboy coding. If we do, people will die. So, yes, we've said 'no' to customers and established best practices - long ago.

My first project

[Anonymous Coward]

When looking back at my first project, I feel the same.

When I look back at my first project, all I can say is no comments....

Quality Over Quantity

[wzinc]

I've found that, no matter what they say, a customer would rather have a program with five features that work properly, than 50 features that are buggy.

I also agree with the guy that said slow down.

Change your paradigm

[mdmkolbe]

Switch to a langauge like Haskell. It will seriously improve the quality of the code you produce even when you go back to your original language.

Stick It to the man

[__aalnoi707]

I find that it's really up to the programmer to come up with the "Best Practices" to coding. I personally hate it when I see code that has 25 nested IF statements. I remember back in High school, one of the other students named is variables X, XX, XXXX, moook, Y, YYY, etc. (it was like reading PERL for the first time.( moook = X + YYY * XX / Y). He was able to read and understand that block of code. Needless to say that I had to stay up late one night to finish the project because he was sick and the project was due the next day. What I learned from that experience is that no matter what every one is going to have there own standards of coding, If you are not happy with the way you coded something, take the time to decide what works for you and clean up the code.

anonymous reader writes

[sm62704]

An anonymous reader writes "I am downright embarrassed by the quality of my code. It is buggy, slow, fragile, and a nightmare to maintain."

Well look on the bright side, your employer is the largest software manufacurer in the world, whose OSes are installed on nearly every computer made, and they pay well. So what's the problem?

Besides, your sloppy code is doing me a favor. When I'm using your database and something breaks, I can blame you and everyone will agree it's your fault. Don't worry about it, all your fellow employees write bad code too.

-mcgrew

Reserved error (-1517); there is no message for this error.

Engineering vs Programming

[Anonymous Coward]

There is no incentive for programmers to produce code that they are 'proud' of.

The whole programming industry is based on shipping out mounds of steaming code that 'works' and 'meets the requirements'.

Programmers have no concerns about liability either, they can't be sued, or held accountable. There are 'metrics' used by some companies (# bugs, # lines/code/day), but these are just meaningless numbers. Anyone can produce 'bug-free' code, but will it meet the requirements, will it run fast?

If they don't build it right on the first iteration, simply try again in a service pack, or better yet, build 2.0, and charge users for the priviledge.

Software Engineers on the other hand, have a different problem. They can be sued, they can be held responsible, and more importantly, their whole education is based on the engineering principle of 'if I don't build this right, people could die...".

While the programmers education is based on how many lines of code they can 'produce' in a given timeframe.

another great source for code improvement

[ajaxlex]

Code Complete - Steve McConnell - this highly regarded book discusses the nuts-and-bolts of software construction, and is a pleasure to read. I'm not familliar with another book that discusses software development at this level. Worth picking up (get the second ed).

I am content with most of *my* code

[mrjb]

I'm content with most of the code that I write for myself, whereas code that I write professionally (read: on a deadline) more frequently leaves something to be desired. My own code is documented (manual+comments), usually quite efficient, and if there are bugs in there usually they are not very serious (forgotten null pointer checks). Of course, when dealing with my own code, I can refactor it as needed and as I please. At work, that's not always possible.

Pride fades with time

[Opportunist]

Generally, whenever I complete a set of code, it's perfect. It's flawless. It's the stunning pinnacle of coding, and it should go on some kind of display page where everyone can marvel at it, worship it and experience its perfection so they may find true enlightenment.

Usually, when I unearth the code 6 months later I wonder if there's any way to get this horrible piece of hacked crap out of the CVS somehow...

It's just that, well, you learn. You improve. Yes, even after more than a decade of coding, you still learn and improve. You learn new tricks, you learn to use new libraries, and you discover better and more efficient ways to use them by using them. So generally, yes, I'm proud of my code. For a while.

Find the problem, not the symptom

[JavaSavant]

If you truly understand software architecture and design, and the rhyme and reason behind the code you're writing - then you should be comfortable with your own abilities and skills. "Cowboy coding" is never going to be a directive of management, and is an entirely different problem from the "get it done" mentality. Any manager is going to insist that systems not be overengineered, and that objective consistently is client satisfaction. The customer *is* always right, and if they're paying for crappy, bloated, slow software - well, that's what you should build for them.

Obviously, this is probably pretty inlikely. Given that a) you're a talented software engineer and b) the client doesn't want you to build lousy software, I would say your problem is simply poor project organization and management. Arbitrary deadlines, poor scope management, refusal to consider bottom-up estimations, no rhyme or reason to task management, and no system of design and review of software will create that "Old West" mentality of software design where chaos rules. It's often not that there's a lack of interest in order, but a complete lack of knowledge to implement it.

If your group has a project manager or architect, they should be responsible for understanding these problems. If you don't have someone in this role, then I would suggest that you pry yourself away from your compiler for a bit and get a bit of an understanding of project management methodologies, SDLC, and more modern software methodologies like Agile. Understand why the process working above you is so flawed, and either try to assert change in this from within, or use that knowledge as your career advances.

The client (and your boss) will never likely see your code. Your shame (for lack of a better word) is not going to gain any empathy unless you can direct your attention at the problems that have put you in this position while at the same time showing how a more structured team environment when it comes to software can be better for the business.

To be honest?

[stonecypher]

I am downright embarrassed by the quality of my code. It is buggy, slow, fragile, and a nightmare to maintain. Do you feel the same way?

No.

Re:To be honest?

[PrescriptionWarning]

I hear that, write well in the first place and you'll never need to regret it!

That said over the last 2 years I've learned a lot about more proper ways to code, and whenever I get a chance to go back to a previous block of code I see about improving it if its worth the effort, otherwise I just go ewww I'll never code like that again. Its all about the learning experience and if you don't like how you code... then stop coding the way you usually do. DUH.

Re:To be honest?

[Anonymous Coward]

WTH was this modded "Informative"? I really dont feel any smarter than before I read it.

I thought it was funny.

Re:To be honest?

[Anonymous Coward]

One of the marks of incompetence is thinking you are competent.
One of the marks of competence is understanding how incompetent you are.

Re:To be honest?

[Anonymous Coward]

WTH was this modded "Informative"? I really dont feel any smarter than before I read it.

I thought it was funny. You mean you didn't get any insight from it?

Re:To be honest?

[Anonymous Coward]

I think what he is saying is not that any code he writes will be an embarrassment, rather he is saying that his code is at the mercy of forces beyond his control or understanding, and in that way suffers in quality.

I remember all of the people in my CS classes that couldn't wait to graduate and start making the "big bucks" and writing some code that actually did something and wasn't a toy, but looking back on it some of the most elegant unblemished code I wrote was during school. It may have been only a toy or proof of concept but at least I understood all of it and the reasons it was being written. If I wanted to really focus on something that especially interested me I could do so without fear that a manager would pull me off the project because of a mysterious change of priority for the company.

Out in the "real world" I have found increasingly disillusioned by competing business interests, priorities, and the general feeling that code is something that can be cranked out like cogs in a factory. Not to mention the fact that in most cases sales or customer service is given priority over technology when it comes to most decisions. The coding horror "software engineering explained" cartoon is pretty accurate.

Re:To be honest?

[xant]

I am downright embarrassed by the quality of my code. It is buggy, slow, fragile, and a nightmare to maintain. Do you feel the same way?

No.

Really? Have you seen his code? It's terrible.

Re:To be honest?

[stonecypher]

Er, no. I thought he was asking whether other people felt the same way of their own code. As such, that's what I answered.

Re:To be honest?

[Anonymous Coward]

IIRC, Goethe said something to the effect of:

The man with insight enough to admit his limitations comes nearest to perfection.

Re:To be honest?

[stonecypher]

Oh, enough with the ad verecundiam nonsense. Goëthe was a fiction writer, and at no point did I hide my limitations. I said I wasn't ashamed of my code. Go play faux deep thinker with the other sixth grade level thinkers in the presidential cabinet.

Incidentally, it's actually a biblical quote, not Goëthe, so even though you're pretending that he ought to know something about humility or the observation of one's limitations, something that anyone familiar with Goëthe's actual history would never do, your ad verecundiam is false. Just because some internet site pulled it out of one of his books doesn't mean he's who coined the term; you might as well suggest that Heaven and Hell were Dante Alghieri's ideas.

Maybe you should try reading Goethe before quoting him again. There's a reason the first three sites that come up with your quote verbatim on google spell his last name three different ways, all wrongly - it's because you've chosen to believe Geocities without reference. Name dropping essentially never makes a person look smart, but given that you misattributed the quote, misspelled the misattribution, and managed even to miss the point of the phrase, well, all I can say is "damn, dude."

There's a big difference between "I have no limits" and "I am not ashamed of my work." If you can't sort that out, better to just not condescend to people in public.

Re:To be honest?

[stonecypher]

One of the other marks of incompetence is bandying about hollow platitudes in order to imply a defect where you don't know there actually to be one; it's called argumentum ad hominem, and you can't pass discretionary writing courses at most decent universities until you've learned not to do it. Surprisingly, just because I'm proud of my work doesn't mean it's crap. Just because you don't know why your code is crap doesn't mean I don't know why my code isn't crap. Go read a book on software process. My defect rates are below one every thousand lines of code (and frankly, I'd be shocked if you had a sense of whether or not that was any good, or even how a person might know that about their own code.)

Oh, and by the by? That second one you want is both non causa pro causa and internally inconsistent. Furthermore, it's absolute horseshit. The vast bulk of the talented programmers who I employ have absolutely no idea what their own skill level is - most of them think themselves average, and the remainder think themselves much better than they actually are. Most children understand that just because it sounds true doesn't mean that it necessarily is true; apparently you do not.

Just because you believe all programmers are incompetent doesn't mean that an engineer must prostrate themselves to be clueful. Grow up.

Re:To be honest?

[stonecypher]

I think what he is saying is not that any code he writes will be an embarrassment, rather he is saying that his code is at the mercy of forces beyond his control or understanding, and in that way suffers in quality.

I think that's entirely a reasonable interpretation of what the original poster said, and it's relatively similar to how I read the same material. I stand, however, resolutely behind my answer, that I do not feel the same way about my own code. I haven't felt that way since the first time I learned a real formal process (in my case COCOMO II, though these days I practice PSP/TSP instead.)

but looking back on it some of the most elegant unblemished code I wrote was during school. It may have been only a toy or proof of concept but at least I understood all of it and the reasons it was being written.

This raises the worrying implication that you do not feel that you understand why your current code - presumably at work - is being written. I don't want to jump to that conclusion; it seems rude. Nonetheless, I see no other way to read that. With all due respect, from my perspective, if you don't know why you're writing the code you're writing, then it should be no surprise that you are neither satisfied with its quality or elegance.

Out in the "real world" I have found increasingly disillusioned by competing business interests, priorities, and the general feeling that code is something that can be cranked out like cogs in a factory. Not to mention the fact that in most cases sales or customer service is given priority over technology when it comes to most decisions.

If you were a carpenter, and the foreman gave you only rotten wood with which to work, that the house collapsed after being built would not be your fault. Similarly, when engineering issues are not given priority in an engineering project, that the project fails is not (necessarily) the engineers' faults. One of the most important things in my personal history of learning to behave like an engineer was when formal process gave me a way to distinguish between problems I caused and problems that were caused externally.

With all due respect, it sounds like your job is fairly broken. (Don't feel bad - that's true of more than eighty percent of software houses, according to RAND.) I was lucky to have a decent environment as my first environment, and as such I knew going into my next several jobs when warning flags started showing up.

The coding horror "software engineering explained" cartoon is pretty accurate.

Maybe, if you feel that way, it might be time to look for a better employer. Believe it or not, they're not all that way. I was once threatened with termination because my boss wanted work on a 4-dimensional 100-cell-edge to scale up to a 10k cell edge in 100x the work (100^4 vs 10000^4, laugh under your breath in 3, 2...) That said, not all bosses are like that. My boss isn't like that, and I'd like to think that I'm not (though were I, I wouldn't know it.)

If you were a boss in a company small enough that you could make Big Changes (tm), wouldn't you? And, don't you think other people like you in that situation would, too? Either you believe that the situation is so broken that success is impossible, or you believe nobody would try to fix things, or you accept that there are better jobs somewhere.

I've had better jobs. Chin up: you can too. Maybe it's time to go looking.

Re:To be honest?

[xant]

My apologies. I seem to have knocked your hat off with that joke.

Actual Software Engineering

[TheSciBoy]

In what other line of work does principal construction begin before the customer has defined what it is they are ordering?

A software is not a product in itself. It's not like an "apple" or an "orange", it's more like a "building" or a "vehicle". A building and a vehicle can be the solution to many different problems. A truck doesn't necessarily solve a customers problem if he's looking for a way to transport people in style from A to B.

But while I think that most people understand this, they have a very fuzzy and indistinct concept of the cost of changing the specification once construction has begun because you can't walk the customer out to the building, point at the construction and say: "To make the changes you require we will have to tear out that wall there, remove all the concrete laid here, that will require a week and scrap more than four tonnes of construction material".

This is where software engineering comes in: With a good model and by sticking to the principle that you begin with a specification from which you construct a series of test to see if the specification has been fulfilled. From the specification a design is made. The design specification is used to implement tests to see that the design has been followed. From the design the code is written and on the code the tests are run.

Now when the customer changes the specification you can look at the design and the code and see (hopefully) how substantial the changes will be and what the cost will be. Your customer will thank you for being more accurate in your estimation, for pointing out the costs (which is the only thing your customer will care about, remember that time is money and is just another type of cost).

I have so far only worked in one workplace where this model was used and it was used very successfully in my opinion. Writing all those documents surely sucked, until it came time for implementation, which was frighteningly quick and painless. The ultimate pride for the well documented, well planned, well concieved and tested code has made me utterly incapable of being satisfied with any other way of working (which is why I've switched jobs a lot).

Changing to a structured approach to working is costly, but the benifits are bountiful and will ultimately save money and time. I can almost promise that while you might lose a customer or some goodwill of a few customers in the interim, in the long run, the customers will flock to you since you are delivering on time, the functionality they asked for.

Re:Actual Software Engineering

[ByOhTek]

In what other line of work does principal construction begin before the customer has defined what it is they are ordering?

I'm not sure of any line of work where that happens, let alone any other.

The rest of your post seems to fairly well go along with 2, 3 and 3a in my post.

Re:Actual Software Engineering

[TheSciBoy]

I'm not sure of any line of work where that happens, let alone any other.

Not exactly sure what you mean, but I think you mean that you don't think that software engineering begins without a definition or specification of what the customer wants. Which isn't exactly my experience. Sure, the customer has a list of things he wants and a problem he wants solved, but it is never (yes, not seldom or rarely, never) complete or very accurate. First order of business before engineering begins would be to ask more questions and build a real idea of what it is the customer actually wants.

This process is fairly well established in ship/house/car/bridge/other-type-of-construction-building but not in software engineering, unfortunately.

Then again, as someone else pointed out in this thread, more often than not the customers demands will change so often and so quickly that you are best to keep your implementation as open as possible so that things can be added and removed on short notice. But this depends on the customer. Medical firms tend to want more stability and aren't as fickle, for example, whereas a web-shop will be sending you daily updates to the specifications.

Re:Actual Software Engineering

[ByOhTek]

Not exactly sure what you mean, but I think you mean that you don't think that software engineering begins without a definition or specification of what the customer wants. Which isn't exactly my experience. Sure, the customer has a list of things he wants and a problem he wants solved, but it is never (yes, not seldom or rarely, never) complete or very accurate. First order of business before engineering begins would be to ask more questions and build a real idea of what it is the customer actually wants.

Innacurate requirements are not the same as nonexistant requirements. I've seen the same with building construction - they find out some things late in the process that need to be fixed sometimes. Starting with inaccurate requirements is not the same as starting without requirements.

Re:Actual Software Engineering

[dubl-u]

In what other line of work does principal construction begin before the customer has defined what it is they are ordering?

One place is in art. Especially collaborative art, like plays and movies. For serial TV shows, it is impossible to define it up front. And for improvisational theater, by definition you don't define it.

See the great book Artful Making if you'd like to learn more about that kind of work, and why modern knowledge work is much more like that than the industrial approach you're following.

Changing to a structured approach to working is costly, but the benifits are bountiful [...]

This is plausible in very specific problem domains where people a) know what they want, and b) what they want won't change. But it is fundamentally impossible in domains that are poorly understood or continuously shifting. It is also impossible if your product development process uses user feedback for planning. All three of these characteristics apply to a lot of web startups.

Take Flickr as an example. In under two years, they went from a side project to a $20m sale. (If they had held out until now, they could have been a $100m sale.) Their initial ideas were ok, but not great. But they released early and often, pushing to production every few hours. And then they listened to their users intently, continuously improving Flickr's fit to their audience's need. That relationship is only possible with an agile approach.

And before people jump on me about anecdotes versus data, I'll point at a VC's look back on companies he funded. Two thirds of his winners significantly reinvented their businesses between funding and success. That's not to say you have to use an agile approach for that. But agile methods are much cheaper in changing circumstances than structured ones, so you'll have to have much deeper pockets to survive.

And just to be clear, I'm not talking about the chaos of code n' fix here. I'm talking about highly disciplined agile methods, where you include practices like test-driven development, acceptance testing, pair programming, collocated teams, in-room product management, aggressive refactoring, short iterations (like a week), and frequent releases (daily to monthly, no more).

Re:Actual Software Engineering

[TheSciBoy]

I'm talking about highly disciplined agile methods, where you include practices like test-driven development, acceptance testing, pair programming, collocated teams, in-room product management, aggressive refactoring, short iterations (like a week), and frequent releases (daily to monthly, no more).

What part of this is not structured? :-)

I think the problem here is that I'm Swedish and that I am not a theorist programmer but rather a practical one. Structured programming appears to be a special type of programming, I may be familiar with it but it's not what I'm referring to in my post. All I meant was that to be able to cope you must be thorough, have a clear policy on what to do and when and be careful how you solve your problems.

Quick iterations and being "agile" in your programming does not necessarily mean that you skip designing tests or that you write specifications and follow plans, it merely means that your plans are flexible enough to cope with rapid changes. So rather than having long meetings with your customer you can have successive releases with feedback.

But I must also point out that for every example you can give with a success story like Flickr, there are 99 abject failures that show how difficult it is to be flexible this way, it demands discipline.

Maybe it is even so that the more flexible and agile you are the more discipline you need to have.

Re:Actual Software Engineering

[dubl-u]

But I must also point out that for every example you can give with a success story like Flickr, there are 99 abject failures that show how difficult it is to be flexible this way, it demands discipline. Maybe it is even so that the more flexible and agile you are the more discipline you need to have.

I agree completely. Without smart, experienced people with the discipline to envision a process, follow it, and adjust as needed, I think any project is screwed.

The thing that kills me about a lot of the formal, high-ceremony, high-documentation methods out there is that they are sold as something to do instead of getting great people and being disciplined. Many people cater to the dumb manager's desire to believe that if they only follow some magic recipe, great software comes out at the end no matter how screwed up your organization is.

Not that some agile process proponents don't also over-promote, but the Agile Manifesto makes it clear that process isn't the answer, which does help limit the damage. :-)

good luck

[jmyers]

"Has anyone convinced their superiors that the customer isn't always right and saying no once in awhile is the best course of action?"

Good luck with that one. Successful technology companies use pie in the sky marketing. Reality does not sell. When you are not saying yes I can do it faster and better then you are whining as far as CEOs are concerned.

I have a great career and made lot of money writing crappy code. My bosses have always loved it because I am fast to produce an end result. I call it prototyping and constantly remind my employer that I am creating a demo of what can be done. But in the end the demo always goes into production. I have seen several programmers much better than I get fired because they could not bring themselves to lower standards. I guess I'm just a code slut.

Be an arsehole

[fozzmeister]

If you want to be proud of your code, you need to say no, and to look realistically at what your being told to do. Then you need to think of a way to achieve the aim without cludging it, basically your contuaally refactoring, rather than just adding functionality

My boss

[Anonymous Coward]

I am downright embarrassed by the quality of my code. It is buggy, slow, fragile, and a nightmare to maintain. Do you feel the same way? If so, then what is holding you back from realizing your full potential?

My boss.

"We don't do design". Of course I tried anyway, but it had to work with his broken database "design". And it was never really designed for the features he wanted crammed in, because his ideas kept changing from one week to the next. The features might have been possible to integrate with the (shadow of) design, but he wanted it done "by next week". Of course it's a nightmare to maintain.

Now, testing on the other hand... Testing always started out with "I'm going to put the current release into production next week", followed by me frantically commenting out half-finished pieces of code to get the thing to even compile. When the testers didn't have time that week, the roll-out got postponed for one week. When the testers still didn't have time, the production system became a very realistic test environment. It wasn't unusual to have him roll back to the old version, because the new one refused to even start (it barely compiled, what do you expect?)

Is anyone surprised that I'm looking for a new job? That I'm looking for something that doesn't have anything to do with development?

New features vs cleaning/debugging

[mujo]

One of the main problems I've experienced against clean/solid code in the industry is that new features will always please management more than debugging and cleaning code.

For instance, in my weekly tasks update, my immediate superior will always prefer, and thus push for, that I say I wrote new features as he enjoys saying "the system now does this" to his superiors. He doesnt sound as cool saying "we spent a week debugging what was already there".

With time the code becomes unmaintanable and you end up having to rewrite the whole thing, or at least large parts, in order to make it progress beyond a certain point.

Ive seen some managers having more foresight about this but most of the time they'll fall in the "new feature" trap...

Management

[Anonymous Coward]

Good leadership is the really hard thing to find.

Most project managers are useless middle management.

Your co-workers are usually yes-people who take whatever hilarious crap the corporates think up and pass it down to you.

They, in turn, are playing a public relations game trying to look good and not drop the stock price.

There is no plan.

A product is an interpretation of a needed technology, designed to make profit, not work well.

These are all insoluble problems of the way the technology industry works.

I agree

[pkbarbiedoll]

I've learned this the hard way at my current position. The powers that be simply cannot think through projects in a technically foreseeable way, and they have a habit of not telling everything they intend to do with the application until after the first beta. I'm learning to plan on worst possible scenarios with everything I do.

The normal response of an inexperienced programmer

[petes_PoV]

.. is to criticise the code they inherit.

All this means is they have a fixed idea of how it should be done and cannot bear to see it done any other way. Frequently (as you found to your cost) the final product is the result of trial-and-error techniques. It's very likely the original programmer thought of and tried the way it should be done, then found the flaws in this approach and adopted methods that produced the results.

It's equally likely that some of the ugly code in any implementation is to get around bugs in the development system, programs it interfaces with or even the O.S. itself. The inexperienced programmer only sees the ugliness of the end result, they assume that the original programmer was dumb/lazy/old-fashioned (because that's what they see in themselves?) and in their arrogance assume that there's nothing worth keeping and only a complete re-write will meet their high standards. If only this was Usually none of the "experience" is documented - only a description of what a module does, not why that method was chosen.

Of course the BIG mistake is to only have one programmer. What happens when they take a break or leave? Everything stops.

as long as my code is unique...

[someone1234]

As long as my code is the only freely available code to do a particular task, and anyone is free to submit patches to refine it, i don't mind to publish it.
Afterall, it is the best way to refine it. My ego doesn't suffer significantly when i meet a better coder.
I just don't like people who criticise but don't submit any fixes.

Yes, I am.. but now of my collegues' code..

[HBSorensen]

I work as an IT consultant in Denmark. Here I come accross a lot of code from other companies, customers and even collegues. And by the Gods of the Computer Chips: Code SUCK!!!!

No error / exception handling. No data validation. And NO FUCKING COMMENTS!

A collegue even removed the Mutexes in a multithread application because : "Data sync takes up too much time.." - result that a very unstable server application.

Just had a "attitude correcting" talk with my boss. It seems I take my job and quality too serious and therefore make my collegues look bad. I was then ordered to "Don't give a shit" about the job and the quality.. QUE?

Before joining this company I have written server software which runs 24/7 ( and has done so since 2000 without breakdowns ). Even on Emb. platforms. And now some idiot tells me that I produce too good quality?

bottom up doesn't work

[virchull]

In my experience (managed a 300+ person team producing millions of lines of code each year), best practices don't come from bottom up. Better practices, like code standards, documentation, etc. can come from the bottom up, but best practices take lots of man-hours, otherwise known as money, invested over years. This will only happen if executive management sees value, invests steadily for years, "encourages" sales and marketing types to play nice while some investment money goes into strange sounding software practices rather than into new products or advertising, and development managers spend their time creating a culture that supports a much higher level of engineering teamwork. Executives have to have the long view via the need to retain large demanding customers, support complex products for long periods, sustain a monopoly, etc. Your run of the mill web site, widget, or IT wonk support sees little value in truly best practices for software. A little better - OK, but it better be quick (says the CEO) - but not best. So if you truly want to experience best practices - and someday maybe push the envelop into uncharted territory for team results, go find a different company, and select them based on their industry reputation for software development. If you ask, you can find them. Otherwise, learn to love better practices.

Nope not really, not a line of it!

[haplo21112]

Most the code I write is written ad-hoc, under the gun with no time for refinement, little testing, never get a chance to loop back and do it better, never gets re-factored, only gets improved if it happens to needs to be patched for a bug.

So not a line of it! I could do better but the circumstances under which it is written don't allow for it.

The key to writing good code, is NOT to write it.

[kbradl1]

I have really gotten onboard with using tested and trusted 3rd party frameworks, or using code generators. I can create about 30-50% of my code using generators. Code generation not only eliminates simple bugs, it enforces a standard practice across the group and keeps the code clean.

My Code Sucks, Or Does It?

[pinkfloyd43]

All code sucks, unless you did it, right? My code, although it might not be the most elegant, usually works, most the time. I tend to
create very basic stuff that I believe anyone can read and understand. Code that works is a dime a dozen, code that can be maintained
by others easily is worth millions!

So many questions, so little time

[cpct0]

1- Yes, I am definitely proud of my code. I have my style, and I'm proud of it. Personally, I tend to code in a "vertical" way, where I will dig a precise topic until no question is unresolved, and where my solution will be the best for many problems that might arisen. My code seldom need rework to do different tasks, and it's quite stable, to the expense of a horrendous amount of time taking to ponder and code. My good friend programmer who works with me is a "horizontal" programmer, he will take all facets of a software in its entirety and will do what is required to make the software work, however, he seldom thinks of all the implications, and his code will frequently need rework, but he can achieve a whole projects in matter of minutes. I know of two other types, one is the bull-programmer, you aim him to some goal, and he will do a straight-run to the goal; do not ever ever think of changing his aim from that point, it's your problem if your aim was not good. Finally, there is the back-bencher, the one who will do what he's comfortable working with, at a precise pace with a precise result, but only working with something he already knows.

Note: these are made-up names, used in my company

As you might understand, each coding style has its own advantage and disadvantage, and there is no real answer on what and how to do something. My kind of programming does not bode well with coding competitions, as I overthink stuff, and frankly, I don't mind, as it's not required for my job anyways. I constantly look at ways to better my code, to understand better algorithms, to add to my personal toolbox. I read a lot on coding, I explore open source projects, I look at what I like and what I hate. I use coding standards.

2- Cowboy practices from companies are not compulsory, but sometimes, they exist. You want to achieve goals at precise times, then, work from there. You might wander around at every version but try not to change in between versions. Even if every week and version, you do a 180 degrees, at least, you have a product that is more and more refined. More changes means more brittle code, that's the drawback, but that's the way it works. Eventually you need to ask for a few days to clean up everything. That's life.

3- Clients are the king. You can convince them their changes are not for the best, but it's all through dialogue. If they are paying and if they want changes, you got no choice but to abide, or look for another contract or another job if you're tired of that.

I'm Lead Dev, at a young startup...

[beyonddeath]

And if there is one thing I've learned over the past 6 months (having no prior experience in management), its that if you do up front design, the code is about 10x easier to write for any non-trivial problem. I dont mean going into full uml diagrams and that shit, as my prof in software engineering said "in ten years working in the field I've only ever seen one person willingly write uml specs before programming, they were russian". But coming up with class interfaces and the overall breakdown of the code before writing it, will result in code that is much more modularized and reusable, not to mention easy to write. That and practice makes perfect. Shit my code from 6 mo's ago is horrifying, and in 6 mo's I'll say that about what I'm writing now. Practice,practice,practice. The only other thing I can suggest is find a team you enjoy working with. Even if the code is not pretty, at least you can have a good time at work. Thats by far the best part of being in a very high growth startup. ;)

Better code style

[Lars Clausen]

My code style has improved a lot the four years I've been out in the workforce. We were fortunate enough to have somebody at the start of the project who really cared about methodology, metrics and style, and it has paid off. We've been using unit tests and code reviews all the way through, together with fairly powerful tools (IntelliJ has nice refactorings). While my coding quality still varies, it is no longer where I'm embarrased, and some of it I can plainly say 'this is the way to solve this problem.' The three practices I have found the most useful are:

  1) Always document your functions and variables[1]. I don't agree with Use The Source, Luke. The source says what's being done, not why, and if the code has an error, you'll translate that error into your thinking about the program rather than fix it. Documenting the code *before* writing it lets you think about it first and forces you to be explicit rather than clever.
  2) Write unit tests first (this is the one I find the hardest to follow). This encourages smaller portions of code and clarifies what the code should do. Plus, it gives you a place to do cowboy programming:)
  3) Refactor mercilessly. Any time I cut-and-paste a chunk of code, I regard it as a candidate for refactoring, even if it's just a couple lines. Making it a new method adds testability, reduces cut-and-paste errors, increases documentation and makes it easier to use that third time.

I'm applying it as I go along to the OSS project I'm maintaining, and it helps both me and others.

-Lars

[1] Except trivial getters and setters. Maybe.

REALITY CHECK: It doesn't matter...

[PatSand]

Folks- While people get all flamed up over GOTOs , global variables, coding styles (and I bet parenthesis placement), the hard reality is this:

Most businesses only care that it works! And works "Well Enough" for their delivery deadlines!

Yes, I was actually trained in good coding practices and the total lifecycle costs of software development, but most places only care about checking the "Done, now ship it" box. A very significant indicator of whether or not they care about code quality and style is this: How beefed up is there QA?

If the QA effort consists of a bunch of people doing things manually, they don't have time to check code; only functionality.

If the QA effort is primarily automated with tools to parse and check code, as well as run serious automated testing, then you have something there.

I'm afraid many shops are now in the mode of "just code it and get it working...we can clean it up in maintenance..."

Often

[jrexilius]

I find that I am usually ashamed of my code when I am rushed. I think that its a sign of my long years of programming and learning as I went.

When I am rushed, many of my old bad habits come through and the most recent "best practices" fall by the wayside.

I know a lot of developers suffer from this as well. Its a lot like fighting, the habits with the most hours behind them come to the front when shit hits the fan.

I also noticed a common thread that refactoring a second or third time always makes huge improvements, but then later iterations start to have diminishing returns..

Code Review

[bobs666]

One good way to slow down would be to put more eyes on the code. Get a projector and stand up in front of 2 or more or your peers and explain the code. Learn to take criticism and learn from the experience.

It's about value to whoever pays the bills.

[Fross]

As a programmer you are often building an application for someone else - someone else is paying the bills, and they want to see value for money. Hence you need to be delivering value, this can be in straight code, but it can be in other ways too.

Generally however, a lot of projects consist of building one application for a specific purpose and then leaving it as it is - this is the problem of the business, not yours - they have no plan for an evolving or expanding system, they want something that can get them kickstarted and able to fund enough money to do their next development, a bridge they will cross when they come to it. And fair enough, usually budgets are so tight on first implementations that an extra 10-20% could make or break that first stage, and without a first stage, the project will go no further, no matter how elegant the code is.

Therefore, as someone who may code something more elegantly and more maintainably, but more slowly, you become less effective and hence less valuable to your employer, than someone who slaps it together in half the time and ends up with a nightmare of spaghetti code and hacks. While the latter approach may make the coder feel they are irreplacable as they are the only one who understands the system, such a system will often be treated as a prototype once funding is secured, and rewritten from scratch.

The only way out of that situation is to avoid it in the first place - don't be forced to work to tight deadlines and have to compromise your work in order to fit a business plan. However, it's a very lucky artist indeed who can pick and choose his work, and is given the time and money to do something that will last. Sometimes we have to make this compromise, but hopefully with more experience you'll be able to negotiate a better position.

I mentioned at the top that you can give value to your employer in other ways: documentation, stability and reliability of your code, hassle-free maintenance, the ability to provide long-term development plans and milestones. These are only useful if your employer is also planning that far ahead. Until then, you may have to concentrate on trying to plan your code ahead of time and anticipating and second-guessing what your employer will want 6 months or 6 years from now.

Are you kidding me?

[sirgoran]

For nearly every company that I've worked for, it's been the same old story. Get it done as quickly as you can, cut as many corners as you can so that we can keep more of the budget by keeping development costs down.
Testing? What's that?
If you can't test it as you're building it you don't last. If you complain about time-lines, you'll be out the door. If you gripe about the feature creep, you end up on the Sh*t-list and they start looking for ways to let you go or force you to quit. Quality left the building years ago in favor of down and dirty coding that simply makes it work. The last project I worked on for a company, I was only given 12 hours to go from drawing board to production. After getting it done and functioning in 14 hours, I got my butt handed to me by a pointy-haired doofus that said I wasted valuable time and needed to "better manage my time".

I'm supposed to listen to a guy that still uses IE as an FTP tool?!

After I quit, it warmed my heart to see that they ended up hiring three people to fill my position.
I tried to be proud of my code while in the corporate world, but it wasn't until I left for a smaller private company (less than 100 employees) that I finally got to a position where I can take pride in the code I write. I can do all the things I know I need to do. I can now document things, comment my code and test until I'm sure that its solid before putting things into production.

-Goran

You're doing every perfect!

[SlappyBastard]

from inception to a point where the client runs out of funding

Isn't taking every penny they have the entire point? Please, no lectures about sustainability -- we all know that most businesses run themselves into the ground pretty fast anyhow. It's better to get their money from them while they have it than during the 20 years they spend settling their debts for pennies on the dollar.

Good, quick, cheap: choose two.

[threaded]

I'm a contractor. I do what the client asks, and essentially it comes down to this trade-off: good, quick, cheap. If they don't allow you the time or resources, then they didn't really want good. If you feel you did as good as possible within the constraints, quit worrying, and stop being embarrassed about your code.

"Proud?" father of a hack

[GoNINzo]

It's one thing to run your business systems well. But I do have to point out that hacks to code and systems are required from time to time. If your business is doing anything beyond just using single package A, there is always integration with other packages. Things go wrong. People have to recover somehow.

I'm particularly... well I'm not proud of this, but I feel accomplished for figuring it out. The pipe command of << stopped working on my jumpstart, and while I don't know WHY it happened, I figured out what it was breaking and worked around it. It's annoying, yes, but at least now google will hopefully pick it up, and the next person who has to do the same ugly ugly hack will not be alone.

In the comic, as a sysadmin, I'm the one who's breaking the branch that I'm tied to, so instead I'm tying it to 10 other small branches that would break one at a time, but collectively, hold together. At least, sometimes that's how it goes. But at least the next person who has the error knows that doing this might work for them.

This might be harsh, but the solution is easy...

[Caine]

Ok, so this might sound a little harsh, but you see, the solution to your problem is this: code better. It really is that simple. Yes, it's nice if you can anchor things with project managers or whatever you have above you, but it's not really necessary.

Having problems with bad interface? Design better interfaces. Jumbled, complex code? Refactor it. Slow execution? Improve the algorithms. There's basically no project that takes longer time by doing things right, more often than not the opposite is true. A good refactor can save tons of time.

There's no magic bullet, however much support you get from superiors or coworkers. The only thing you can do is simply write better code.

Always write code...

[ebbe11]

...as if the guy who is going to maintain it is a 6'6" tall two feet wide bodybuilding psychopath who knows where you live.

Same here

[codeboost]

I often feel the same way about the code I write.
I've also been involved in projects with 'dynamic' specifications, which required a lot of re-writes and architecture changes.
I bet when you write your code, you seal it in and make it as efficient as possible, only to discover that it is not compatible with the new specs and the required hacks make it ugly and buggy.
But there's a positive in every situation. In time, I've discovered that my code has become more 'spec-change proof', I started to anticipate changes and was forced to write more modular and abstract code.

1. When designing your classes or modules, make sure you make them truly 'unaware' of the rest of the world - create small modules or 'components', which can be re-used or shuffled around to adapt to the new changes.
2. Use a strong standards-compliant library and try to adapt their architecture and even syntax style. For instance, in C++, I would highly recommend QT, as it has a beautiful architecture and forces you to use the signal-slot mechanism, which helps a lot in designing truly component-based code. It is also open source and cross-platform.
3. Plan ahead. The many bugs are usually a sign that the algorithm or architecture isn't thouroughly thought through (TTT). Although I know that for some people, coding is more interesting than planning ahead, so try to plan while coding.
4. Don't get discouraged. Every mistake is a lesson learned. Lots of lessons learned = experience. Remember, it is the path that matters.

Test As You Go, Refactor Fearlessly

[Anonymous Coward]

There have been allusions to this in other posts, but automated testing helps the quality of your code greatly. It's something you can start doing on your own without reference to other developers, and when your code works better you can roll it out more widely.

The greatest benefit to code quality is that you can refactor fearlessly.

I say this having had experience of both sides of the coin in the last year. A year ago I built a test framework for the application I was working on. There was already a comprehensive test suite for other areas of the product so it was easy to just plug all the new tests into that, but having automated tests for this application made a phenomenal difference to its stability and reliability.

Then nine months ago we brought a new application in-house. Its operation was reputedly very good, but it needed to be updated to cope with a new environment. The code was superficially quite well written, although it had no comments. And there were no automated tests.

Suffice it to say that the last nine months have been less than entertaining. Without automated tests in any part of the new (to us) application, the rework and refactoring required has been next to impossible.

So, get that automated test suite in place now. You will be happier for it, and your code will be better.

Clearly the author and I have something in common.

[gru3hunt3r]

Clearly the author and I have something in common, we must have had a lot of the same employers.

I routinely find myself being the guy they always seem to call to clean up somebody else's shit. My entire career has been spent cleaning up other peoples messes, trust me - it makes you a better programmer.

Try maintaining and refactoring a few old programs and/or keeping a job for 5+ years.
Ready data structures and code-theory books, they help too.

If you want your code to be better...

[kunakida]

I am assuming you want to improve your coding for maintainability and such.
However it is also reasonable to reserve your best coding efforts for code that will be used heavily by others, and spend less time on throwaway code.

Remember that the more code you put in, the fancier your coding structures get, the more comments that go unmaintained, the more difficult your code will be to follow.

Here are some rules you can follow that will help you no matter what language you use:

Rule #1: since the more code you put in, the worse it will be, it follows that putting in less code, or even removing some is always a good idea. Refactor your code mercilessly.

Rule #2: reduce your function/method argument counts where possible. You can group arguments together into a stucture, or hold some in member attributes as object state, but _only_ if it makes sense to do so. Passing _unrelated_ arguments through member variables can lead to a yo-yo coding style that is more difficult to follow and induce unwanted state on an object (ie. unnecessary coupling). Sometimes, to reduce argument count, it is easier to break up the method into multiple ones. Anything above 4 arguments should be reviewed. Anything above 6, you should make a serious attempt to reduce.

Rule #3: use proper english. Methods should start with a proper verb and be followed by adjectives and nouns. Proper spelling should be used. Avoid made up acronyms (Microsoft code is the worst for this)
The effect you are trying to achieve is to make your code literate (not quite so much as in Knuth)

Rule #4: make variable/argument/method names meaningful. The variable name should describe what it contains. eg. index, count, accumulator. Don't use short forms or single letters. If you can't come up with a good description, and it is a trivial variable, then you can do the Smalltalk trick of calling it after the type. e.g. aString, theNumber, anElement. If a method name is hard to understand, then someone trying to follow the code may have to do a lookup of some sort such as looking at the method comments if they are visible (or perhaps even calling the original coder) and it will break their focus. If you are in doubt about what to name something, go find a dictionary or a thesaurus. Don't just name it something junky and meaningless.

Rule #5: make the code obvious. No fancy coding tricks that lead newbies astray. Unless it can't be avoided.

Rule #6: comment only when not obvious. If the code is the least bit non-obvious (because it can't be avoided), then add a small comment above it or beside it. Otherwise, let the code speak for itself.
Too many comments that just repeat what is obvious make the code look like gibberish. And that volume of commenting usually gets out of sync with the code as it gets maintained by people passing through. Just comment the important and non-obvious stuff, and maintainers may be willing to update the comments too.

Rule #7: keep your functions/methods small. A good size to aim for is 5 lines of code. 30 lines can be OK if an algorithm warrants it. More than that and you need to consider splitting it apart.
Try to make the finer methods still meaningful/useful by themselves. Ideally, each function/method should be independent of the others. Make it obvious when they are not e.g. private adjustAmountHelper()

Practice the above rules faithfully and you will already see an amazing improvement.

If you want more rules than that, and you are on-side with your boss, you can try looking at a coding standard, such as

C++ Programming Guidelines, Plum and Saks

Despite the C++ in the name, the concepts in the book are fairly applicable to other languages as well.

I have had bosses that wouldn't endorse any coding style guidelines at all until I presented them with the Plum and Saks book. Some bosses just need to know they are not following your arbitrary standard, and presenting them with an actual book or website is all you need

Proudest of ...

[smcdow]

... the code that I've written that actually works (eg does something useful) and that has actually shipped.

In the course of my career, it turns out that more often than not, the code that's simultaneously been the most useful and that has actually shipped has been my cowboy code: quick-n-dirty programs; bash-scripts, perl-scripts, one-offs, and the like.

I've also produced a lot of code under "best practices", and I've found that while this is useful (and it's generally the right way to do things), this code has a tendency to never ship. It (along with a lot of other useful code written by a lot of smart programmers) tends to gets stuck somewhere in the "process" and languishes. Sometimes, it eventually oozes out of the "process" and ships. More often, it just dies a lonely death somewhere in the repository.

I don't care about code that isn't useful or that never gets used. It could be beautiful, well designed, easy-to-maintain code. But if it never ships and never gets used, it's absolutely worthless.

So, yeah. I'm most proud of my cowboy code that has been shipped and that gets used. It may not be fun to read or maintain, but by God, it's useful and it's getting used. That's the primary goal of this industry.

Re:Proudest of ...

[Actually, I do RTFA]

I agree. The code I'm proudest of was a set of horrible hacks (due to the language choosen), has no comments, but it worked perfectly and was solid. (It had no comments because I wrote it in 3 days while on a caffine high and it "needing to get done". When I went back to comment it (after my nap while the build was made/shipped to QA) I didn't understand what I had done.)

But that was the code I was proudest of. I'm also very proud of the program I am working on and the architecture it has. I'm proud that it is documented, and well-designed, and has classes where random hacks go to die, etc. But I think the thing is, the better your architecture/planning, the less proud you can be of any piece of code, because it fits in well, and thus is not clever. But the prouder (more proud?) you can be of the project.

My worst coded app - how wonderful it was!

[PortHaven]

I was a computer science major. Working as a lab tech/shipping clerk for a company that pretty much used Macs and FileMakerPro back when...well, NO ONE USED MACS for non-design business. *lol* They were Mac before PPC processor Macs were around.

Anyways, we had numerous issues with properly labelling our products. I had given my notice to the company. The last week was kind of slow. So I hacked out a really crappily-coded app that would let you enter a lot #. And then allow you to select the brand. The program would automatically select the proper label types for printing.

Vwaala!!!

It worked. This had been a request of the shipping department for a couple of years. IT said it'd be weeks and weeks of work. I was done in 3 days. Sure the program was crap (I used stacked IF/ELSE IF statements because I did not know how to create a case/switch statement in FileMaker Pro's coding environment.)

That said, it wound up being a God-send for my old supervisor. Greatly improved the shipping time and greatly reduced the shipping errors. So the end result - crappy code created in 3-days saved thousands of dollars for the company.

Java and C++ vs PHP

[mulhollandj]

I used to be able to write really good Java and C++ code. I know write mostly PHP code and I can honestly say it is terrible in comparison. Does anybody know how to write good PHP code? I learned how to do it for Java and C++ but am still learning when it comes to PHP.

self-help solution

[aristolochene]

10 print "my code rocks, thanks for asking" 20 goto 10

It depends on who it's for

[macemoneta]

The code I write for commercial use tends to start ugly, but functional. Its development is driven by schedules and fluctuating specifications. If the code has a long life, and I am maintaining my own code, it tends to gets more beautiful over time as I improve it.

The code I write for myself starts off being beautiful. It does exactly what I want, in the way I think of as best. Over time, as I learn more, I start to see flaws and the code gets uglier. I tend to recode my own stuff more frequently to more efficient and elegant implementations.

In both cases, there are some small segments, like a subroutine, that I consider gems. They are beautiful to look at, and I carry these from project to project, almost as a seed.

For some people, coding is a trade. For some it's an art. In most cases, it's a mix of the two. The proportion is what I think changes the perception. Of course, no one but another programmer can even see the beauty in the code, and in many ways that's a shame.

Change Will Always Come...

[Koldark]

...It doesn't matter if they sign off on it and you charge them double for "extra features". There is always something they forgot about. All you can do it learn to design your program so you can make changes easier.

Comment your code

[dgun]

Comment your code well and it does not suck. Don't comment your code, or comment it poorly, and it sucks to the point of being worthless.

I had much rather implement something from scratch than have to walk through code and try to read someone's mind. And this goes equally for open source code. You haven't done me any favors if you GPL your code but don't provide adequate comments or documentation.

Cowboy coding

[Lalo Martins]

> Have any developers here successfully lobbied their company to stop or cut back on 'cowboy coding' and adopt best practices?

I tried and I tried and I tried. Now I'm about to vote with my feet; after a given point, it becomes the only sane alternative.

Economics

[chord.wav]

Economics has transformed the:
"Make it work, make it fast, make it nice"
to:
"Make it work, distribute it, then make it fast and then nice through service packs/updates"

And sometimes you don't even have the chance to make it work properly. So you ship a non working product and then make it work using service packs.

My experience

[Anonymous Coward]

I got my first programming job this year straight out of college. I was armed with a software engineering degree and found a company looking for a cheap programmer.

My first week I was handed an ungodly mess of a system written almost entirely in VBScript with some minor C# parts. It was a nightmare. The previous programmer had left me 10 modules that were "60%" done. Which essentially meant I had 10 modules that were completely no working messes. The best part is that the day I started the project was already 6 months overdue. I almost quit my first week.

The director of engineering came to my first week and told me the hope of the project rested on me. Millions of dollars of sales rested on my abilities to finish it all in 2 months. I have no idea why you would risk millions on a programmer with no experience instead of hiring a few with some.

Anyways, I finished in just a little over 2 months. By finished I mean I rushed out an untested mess to customers. I told my boss it was not tested and he replied that our customers would test it for us. So 6 customers got totally useless systems and paid boat loads of money for them. It was enough to shut them up for awhile.

I am now in my 6th month of employment and the system is still not 100% complete. Its almost there and the pieces that are done are tested. Keep in mind I also spent 2 months on the road installing said system.

I learned that sometimes you just have to do what your boss tells you even though it sucks. Probably not the greatest lesson to learn. I am also now the proud owner of some working code that will be a monster to maintain. My hope is I will be gone by then and the next guy will worry about it. Basically, by the time anyone realizes how horrible the system is I will be gone. This cycle will repeat again and again here due to this management attitude. Also the fact that we sell ideas and not products can't help. The system was sold before 1 line of code was even written with 6 month guaranteed delivery.

The formula is:

1) Promise what you don;t have
2) Hire no experience cheap programmer
3) Give them the impossible task of hitting deadline
4) ????
5) Lose Money
6) Repeat

Ugly code

[tobe]

This is a subject which has been exercising me greatly recently.

Good code to me is readable, obvious and 'efficient enough'.

Readability is a combination of whitespace, layout and good choice of symbol naming. It's got to be pleasing to the eye and easy to scan through without missing some important fact of execution. I should be able to figure out 98% of what a variable/function is just by knowing it's name. If the only way to encapsulate that sufficiently is to have a symbol something like DoXThenY then I'd rather have DoX and DoY.

'Efficient enough' is simple. Does it do what it has to do in the time allocated to it? For 90% of software this is a pretty undemanding requirement since to most users the difference between 1msec and 100 is neither here nor there. The remaining 10% is either real-time or very large data sets (and is where I've spent the majority of my career). In my experience the majority of efficiency problems in these two arenas are usually algorithmic in nature. For real-time it tends to be about how you use the hardware (cache miss, context switches, blocking I/O etc) for large data-sets it tends to be data structure related (using a list when an n-tree is faster etc).

Obvious is the difficult one. What's obvious to one coder is not necessarily obvious to the next guy. There's one overriding principle I've found to stand me in good stead in this regard. I constantly ask myself: "Is this the simplest possible *correct* way of doing this?". Simplest is not always in the least lines of code but it is often roughly equivalent. Simple also suggests a minimum of coupling. For functions this means the smallest set of args I can get away with. For methods this extends to the smallest number of members I can touch. Code paths should generally be straight through and down the page. Recursion (and same-thread re-entrancy) should be reserved for recursive problems.

The other great producer of non-obvious code is OO (or rather poor OO programmers). It takes time to become a good OO programmer. Years, I would say. The most confusing code I've seen has consistently been written by people who just don't 'get' OO, who perhaps have read a few patterns books and then go off in completely the wrong direction making problems fit inappropriate patterns and solving procedural tasks with labyrinthine object hierarchies and call-graphs.

And then.. after you've pared your code down to the very barest essentials, when your call graph is easy to visualise, your data structures clear and your source reads like a well written instruction manual on how to solve the problem you were tasked with.. if you are left with some section that is irreducibly non-obvious: COMMENT IT !!

Gang of Four

[Dan667]

Design Patterns (http://en.wikipedia.org/wiki/Design_Patterns) can really help out with maintainability and flexibility. Makes everything easier if you pick the right ones for the task at hand.

Re:Gang of Four

[Chysn]

Definitely a good book to have around, but if you've got to have a pretty solid grasp of object-oriented techniques already for it to make much sense. It looks like the original poster needs something more fundamental.

Re:Gang of Four

[Dan667]

I agree there are some fundamentals that may be more important first, but I have been re-architecting patterns into a code base I inherited and I think it could help. In one example, the original author was cut and pasting a 2000-3000 line block of code all over the place and then modifying it for the task. I took all of these and used a strategy pattern to put that block of code in one library that I have been working over that one library to make it more readable and easier to maintain. Dropped 10,000 lines+ of dead weight. That really helps if you need to clean up spaghetti code.

Sometimes

[Apreche]

I'm proud of my code when I actually try to write quality code, and I write it from scratch. The problem is that most often at work I am modifying crappy code, or writing code that is built on top of crappy old code. The crap is contagious, and pride flies out the window.

Get it in writing

[Anonymous Coward]

Generally, before I do anything major from a coding perspective, I get a clearly defined set of objectives for the software. It won't necessarily eliminate drift of a project, but it gives you something solid to go on when it comes time to question why something is changing. Nothing has quite the same weight as something the customer already signed off on.

Buy and read...

[Chysn]

...The Pragmatic Programmer by Andrew Hunt and David Thomas.

Indicating issues can be a problem.

[Midnight Thunder]

Now you're upset and become very vocal about the problems you now have to deal with.

From my experience with one company, that is about the same time as the ask you to leave. Granted not all companies are like that, but some are and you have to decide what management decides is good for the company. Remember management rarely, if ever, see the code, so they can't appreciate the real issue. To some guys in management its just the rantings of one of the developers.

The 2 strongest defenses

[sjames]

There are two good ways to defend against shifting requirements.

First, keep in mind during design that changes will happen. They may be in 5 years or they may happen before the first line of code is written. If your design is modular and consistantly uses a decent internal API, many changes won't require a great deal of pain.

The second defense is the "change order". If you do not have a change order process in place, the customer will expect to make major revisions at the last minute without consequence. In turn, this will result in crappy code since the project will suddenly be late and go from profitable to a net loss.

OTOH, if you gracefully hear the customer out, then produce a change order for them to sign which outlines how much longer it will take and how much more it will cost, all is well. They'll either tell you to forget about the change or they'll approve it and the extra work is extra profit. There may be a few customers who will cancel the project in a huff, but that was their choice to make. At least you don't get the reputation for producing fragile bug ridden unmaintainable junk.

A useful rule of thumb there is that if you can accomplish the change more uickly than you can produce the change order, just do it to keep the customer happy. If that encourages them to bury you in trivial changes, you can always gather them up into a change order at that point and explain that the project is now too far along to trivially make those changes.

Re:The normal response of an inexperienced program

[mrjb]

.. is to criticise the code they inherit.
All this means is they have a fixed idea of how it should be done and cannot bear to see it done any other way.

I criticize the code I inherit, but with 20 years of solid programming experience would hardly call myself inexperienced. There are many ways of doing things right, but littering code with globals, GOTO statements, using undecipherable variable names, failing to comment code isn't one of them.

Unfortunately, this accurately describes the code base I am currently working on. Sometimes, criticisms are deserved.

Source code...

[aLEczapKA]

Source code is like shit. It stinks if it's not yours...

Maybe

[protomala]

It's hard to be proud of your code if it's mixed with old one.
I would say yes if I could start a project from zero and build it, but when your mission is to maintain old code fixing bugs while developing new features over it, there is little you can do to make it beautiful and clean :-P

And the first step is

[plopez]

Realizing your code is crap. This is the first step to becoming a good programmer. The second step is educating yourself and working toward improvement. This is the path of wisdom. To use an old cliche', it is a journey not a destination. It is only the inexperienced and the narcissistic bastards who believe their code to be perfect, holy and pure. The inexperienced can be forgiven the narcissists should not be.

Maybe we should develop a 12 step method to improve coding skills?

Anyone?

Good Code Vs. Bad Code

[Biffers]

3/4 of the things that make code good vs. bad is error checking and commenting. If you check the return code of everything and account for all possible errors in your code, you will become a good coder. As far as spacing and comments go, if you make your code neat and very readable by inserting comments where they should be, other programmers that have to read your stuff will appreciate it. Sure there are other things that have been mentioned in this thread and I agree with a lot of them, but being anal about your error checking is the best way to start writing good code.

when i feel bad about my code...

[Anonymous Coward]

...I try and make it look nice, and if i really want to feel good I try and learn something in the process.

Teaching Horrible Code

[Anonymous Coward]

I'm a CS student at a canadian university. We have a professor who is very proud of his code. His terrible, incomprehensible, code.

If he was teaching theory, it would be understandable, but this is a second year Java course. And he's breaking every standard. How can I speak to him? How do you deal with a superior who codes terribly?

Posting as AC

Note to self

[gencha]

Never hire Zonk.

Proud?

[jandersen]

I wouldn't say I feel proud - I feel confident. I think after a while (OK, several years, then) you find a style of programming that is 'right' in that it works for you. It's like anything else in life; when you start on doing something new, you will probably not do the best of jobs, but after some time it will be routine.

The trick, of course, is to get into the right routine so it doesn't become simply bad habits. I find these rules help:

1. Take the time to write your code well.
2. Be willing to rewrite bad code.
3. Maintainability is usually more important than speed.
4. Don't let managers bully you.

Point 1 and 4 are probably more important than you would think. It is no use writing code quickly, if you end up spending ages debugging and maintaining it. Managers of all kinds are often one of the biggest reasons why programmers produce bad code - they often don't know much about actually producing code, and if they don't know much about leadership either, they think that you will work harder and better if you are kept under pressure; but all that achieves is to make people not take the time needed.

Sometimes whole groups are

[Tzinger]

Believe it or not, there are some large groups that are adopting the SEI's PSP (personal software process) and TSP (team software process). Such groups have a clear understanding of how individuals and teams contribute to potential defects and have taken a lot of trouble to eliminate the problems.

Such groups see significantly higher productivity and quality. It is painful to start this process but it does provide the results advertised.

Other People's Code

[Anonymous Coward]

My best work, was that which I've done for myself or my own clients where I could design it from the ground up and I was the only one writing code for it. Then you can do some beautiful stuff with PHP (a language often slammed for poor code quality). By contrast, at my day job I use ASP or .NET (people often claim these languages make for better quality code than PHP) and it's the ugliest mess you've ever seen. Nothing is object oriented, functions are repeatedly declared because we have no reused library files because the IT dept has declared that relative include paths are a security risk *rolls eyes*, so there's no code reuse. Tons of legacy code is commented out and left in there, and there are even spelling mistakes in the function or variable names. Add to that the culture of just get it done, and constant scope changes, and well, you can imagine. I once started up a flowcharting program to diagram a particularly complicated set of logic I was getting ready to write, and I was reprimanded for not starting coding right away. Planning is a waste of time I guess. In my spare time I fix spelling mistakes in variable names and removed old commented out code that has long since stopped being relevant, and tried to clean things up. But, it's one step forward, two steps back. Don't get me started on security. It's the culture you work in, more than the language.

From someone that doesn't code...

[PenguinBoyDave]

Frankly, I'm impressed by any code, and I think you should be proud of your code, regardless of whether or not it is perfect. It is all a part of a learning process. Even coders that I know who have been doing it for years tell me they are always looking for ways to make their stuff better. I can't code, although I'm learning.

If you can code, you've impressed me because you have done something that I would like to do. You can critique your own work, and that is fine, but I think it goes without saying that people are going to do their best to write quality code, and if you've done your best, then be proud of it.

Just my non-coding two cents.

Haven't you learned anything?

[jjb3rd]

Looking back at my old code I find that a lot of it is crap. I do find various aspects of what I've done in the past to be practices that I like to perfect in the future. The problem is, as the poster notes, that you're writing something for your employer to get a job done quickly and as long as it works at all it's good enough...next task. So, a lot of anyone's old code is bound to have a lot of rushed, poorly thought out half efforts. That said, I have found that many projects I've started on my own (and often effectively abandoned) turn out very aesthetically pleasing, though tend to get grandiose in scope or attempt the improbable (I'm smart enough to make my own 3D physics engine...I'll just whip that out...then after a month of heavy physics reading you find yourself looking into M theory instead of having any working code to speak of except the surrounding code...sigh). At any rate, I've had the luxury of having a lot of artistic freedom because I've worked with small companies, so I've explored and expanded several pet ideas into full fledged production systems, which is pretty fun.

Re:The normal response of an inexperienced program

[Jesus_666]

Of course, the smart way to use dirty workarounds is to document where and why you used them. That way future generations will see why your code is so ugly and perhaps not run into the same problems again when they decide to clean up your stuff.

Re:Getting better. - BillG is that you?

[Anonymous Coward]

I know that I can't help but look back at older projects and think that there are better ways to do what I've done. Now I know better. Now I'll write things in a more efficient and maintainable way. I can only hope that in a few years I'll look back at the code I write this week and have an even better, cleaner, faster, and more maintainable way to do it.

BillG is that you??

Re:The normal response of an inexperienced program

[Anonymous Coward]

Man.. I came into an organization and saw this gem:


LOGDIR=/opt/oracle/logs

cd ${LOGDIR}
rm -rf *


The above ran as root. I'm hardly a graybeard programmer, but that just gave me chills because they wanted me to help with the code.

Perspective and Experience

[martyb]

Many good comments already. I'd like to add some based on my experiences since 1972.

Background: I was fortunate to be introduced to structured programming early on. I've used, and helped develop/test tools to implement, various coding methodologies (CASE, anyone?) I've worked on operating systems and compilers. Yes, plural on each of those. I've worked at huge multi-nationals and a 3-man startup.

Observations:

• I've written crap code. I think it's part of the rite of passage. I did the best I could with what I knew, and when I knew better, I tried to do better.
• I've read books and taken courses, but there's no comparison to just diving in and reading LOTS of OTHER PEOPLE's code... and then learning from it.
• Attitude is important. There is a HUGE difference between "That's stupid" and "Why did they do THAT?" Be open to be educated.
• Be organized. In your thinking, notes, and code. In my experience, bugs tend to congregate at the interfaces. Be it a procedure call or return or in an interrupt handler, I try to keep things as clean as possible. Hacks WILL come back and bite me/others.
• Make junk stick out. When I'm pressed for time and know I'm taking a shortcut, I flag it as such. It's easier for me to find a needle in a haystack if I use BIG needles.

Lastly, here is a quotation I found back in the 80's (IIRC from someone at SofTech) and it has guided my thinking ever since:
Strive to understand your problem.
Don't try to solve it.
A fully-stated problem
embodies its solution.

Re:Perspective and Experience

[vikstar]

Strive to understand your problem.
Don't try to solve it.
A fully-stated problem
embodies its solution. P=NP?

Re:Perspective and Experience

[maxume]

I've often thought that teaching problem identification(instead of problem solving) would go a long way toward making our schools better. Even just changing the name and doing the same stuff.

Re:Perspective and Experience

[martyb]

Strive to understand your problem.
Don't try to solve it.
A fully-stated problem
embodies its solution. P=NP?

YES!!! I am in absolute awe. It's the occasional gem such as what you posted that keeps me coming back here these past 10 years.

In just 5 characters, you have managed to communicate you do understand what I expressed. Further, by having given a salient example of a currently unsolved problem in theoretical computer science, you have shown that being unable to solve the problem, provides a solution in being able to state that it cannot be solved. E.g. when a PHB reports an application is running too slow and demands it be made faster, you discover that it CANNOT be made faster - and THAT is the solution.

For those who may not understand what vikstar was referring to, please see: P=NP problem. Here's the wiki summary:

The relationship between the complexity classes P and NP is an unsolved question in theoretical computer science. It is considered to be the most important problem in the field - the Clay Mathematics Institute has offered a $1 million US prize for the first correct proof.

In essence, the P = NP question asks: if 'yes'-answers to a 'yes'-or-'no'-question can be verified quickly, can the answers themselves also be computed quickly? In this context, "quickly" means "in polynomial time".

Consider, for instance, the subset-sum problem, an example of a problem which is easy to verify, but whose answer is believed (but not proven) to be difficult to compute. Given a set of integers, does some nonempty subset of them sum to 0? For instance, does a subset of the set {-2, -3, 15, 14, 7, -10} add up to 0? The answer is YES, though it may take a while to find a subset that does, depending on its size. On the other hand, if someone claims that the answer is "YES, because {-2, -3, -10, 15} add up to zero", then we can quickly check that with a few additions. Verifying that the subset adds up to zero is much faster than finding the subset in the first place. The information needed to verify a positive answer is also called a certificate. So we conclude that given the right certificates, positive answers to our problem can be verified quickly (in polynomial time) and that's why this problem is in NP.

An answer to the P = NP question would determine whether problems like SUBSET-SUM are as easy to compute as to verify. If it turned out P does not equal NP, it would mean that some NP problems are substantially harder to compute than to verify.

The restriction to YES/NO problems doesn't really make a difference; even if we allow more complicated answers, the resulting problem (whether FP = FNP) is equivalent.

Re:Perspective and Experience

[Geminii]

Strive to understand your problem.

Agreed. I was once called upon to write a DNS checker for a massive nationwide network. It was to read in all the internal DNS records my employer was responsible for, compare the IPs to the hostnames, see if they matched the network naming/address conventions, and flag any discrepancies (typos, wrong DHCP settings) for the attention of the network admins to repair.

Did I mention that not only was I not actually a programmer, but had never written anything more complex than Windows batch files before? Yeah, but you try telling that to my bosses.

So there I was, stuck in a little room away from everyone else, and told to write this thing. I decided that the elegant solution would be to have the program derive the naming convention rules from the thousands of DNS records and flag records which didn't mesh with the majority. This would allow it to work even if the entire naming system was redesigned at any future date.

So I went to work with a will, a plain text editor, and a "For Dummies" book. I won't pretend that it wasn't a slow, painful process moving from zero programming knowledge to "utter crap, but it runs and gives the required result". Eventually, I had the resulting mess nailed down and had already had some promising preliminary results from the DNS records of smallish company subnets. So I grabbed the entire DNS list, fed it to the program, and went home for the night.

The next day, a couple of hundred records had been identified as non-matching, and I took them to the network admins. I thought this was the end of the project, until my manager called me in a snit, saying that the network admins were complaining that the items I had given them actually matched the naming convention just fine.

It was my fault, of course. No, I hadn't reversed the keep/discard code at the last minute or anything. The records the program had flagged were exactly those it had been told to identify.

But, as I should have realised, singling out inconsistent records only works when more than 50% of the company DNS is correct in the first place.

No idea what you are talking about...

[p5]

If I find any problems of the sort, my India teams fixes the problem right away!

This is of course after I have 5 conference calls, 7 pictures, 3 DFDs, 9 code examples, and 10 emails later.

if you can't understand it, it's broken

[Anonymous Coward]

I like working with terse,object-oriented languages like Smalltalk and Ruby. All code could be written such that the purpose is hidden, or you can make careful choices that make the line speak for itself. Comments then are needed much less often. Best practice: write the automated test before the code. Get the most modern tools you can (the good news being that they're nearly all open source). Better code requires discipline, hard work with calm reflection & focus. Better code comes from a sort of zen outlook. I've worked as a coder for 20 years and everything I've worked on has gone to production use (that's kind of rare, or even unique, I'd think) but I've worked with some giants who make me feel as if I'm a self-taught gradeschool whacker... maybe they're aliens.

No

[wasabii]

Actually I quite like my code. It's usually well structured, well commented, built on sound principals. I usually abstract it one more step than required so as to adapt it to changing business needs. I have great conventions about organization, case, functionality. It's completely source controlled. Planned features. Loosely coupled.

What the hell is your problem? Are you just lazy or something? Shut up and write better code?

My code is ok

[Anonymous Coward]

People have to work on my code while I am still there, just given the nature of our environment. We are all over each other's code. That's just how we roll in our office.

So I think my code is ok. It's not amazing or anything, but most of the time elegance is more important than amazement.

In answer to the article's question...the thing that holds me back the most is one of my managers. He is very much a micro-manager, tends to grossly oversimplify problems, and thinks he is a much better developer than he actually is. He is very good at telling us precisely how to do something and then blaming us for its failures later. When we try to demonstrate the harm that his presence causes, his ego jumps in, insisting that without his level of direction nothing would work at all.

He also happens to be the one that signs my paychecks. So, there is only so much I can do.

Re:My code is ok

[cayenne8]

"He also happens to be the one that signs my paychecks. So, there is only so much I can do."

You know...I 'used' to get all upset about office politics...how requirements were screwed, this...that...etc.

When I finally realized that is the job is ONLY a paycheck...it is not my life, it is not even remotely a personal thing, just business and a paycheck....my life got much easier. I'll do what they want, I'll change what they want to the best of my ability, in the end, all that matters is getting a paycheck, the bigger the better.

This also helps to realize, there is always another job willing to sign a paycheck for you...you are not stuck, if someone offers me more $$, I will immediately go that way, no malice, it is all just business.

Once you can get into that mindset, your life will be much better, less stressful, and you make more $$ as you go along.

Re:My code is ok

[HeronBlademaster]

The trouble is when you actually care about the code you write (I'm one of those people that likes to do it right, not necessarily fast). It's hard to be in the mindset you describe when you care.

The job I'm at right now lets me write code the way I want - the right way, not necessarily the fast way - and even though I could make more working as a .NET programmer for my math professor, or as a database admin for some local company, or whatever, I'm going to stay at my current job because even though they don't let me fix some things that *should* be fixed ("noone has complained about that, so it's not a bug") and that irks me to no end, they let me write quality code for the things I can work on. There is something to be said for that kind of job.

Re:My code is ok

[coryking]

Not to diss, but writing good code "the right way" is overrated. Good code, to me, is something that is useful to other people. The best code is code that is used by people who could care less about technology or the code. Your definition of good code, I'm sorry to say, provides little value to anybody but yourself. Too me, that is waste of your talents and is in a way selfish.

As depressing as it seems, your users only see the end result. We as programmers should be more concerned with pleasing our users by delivering applications that meet and exceed the needs of our users. Sally in accounting could care less about your "good code", and 99.99999% of the people on web care less when I optimize some query (even though I personally get emmense satisfaction from doing so).

My advice to anybody who things "good code" is important? Stop worrying about it. Get your jollies off from the compliments you get on how much pleasure others get in the user experience you designed. Put the energy into making their life a little more fun. Helping others is more rewarding then cleaning code.

My $0.02.

Re:My code is ok

[HeronBlademaster]

I'm not talking about cleaning code, I'm talking about writing it correctly in the first place. I happen to like writing clean, "good" code.

Are you seriously telling me to stop enjoying my job? You're telling me it's selfish to write good code and take enjoyment out of it? And here I thought my employer and future coworkers would benefit from maintaining clean, well-written code.

And you're wrong about my users too - the code I write directly affects the users' experience with our software. If I write it clean and "good" in the first place, the chance that there will be bugs in it is much smaller - in other words, the chance that something will inhibit the users' workflow is much smaller.

People like you, who don't think "good code" is important, are the people making it hard for the rest of us to maintain codebases after you leave. *That* is what is selfish - writing hard-to-maintain and hard-to-understand code just because it's easier in the immediate sense.

Optimizing queries *does* affect a user's experience, especially if they're waiting on the result. If I make a 15 second process take 10 seconds by taking an extra two hours to plan it out right, I just saved a lot more time than I spent (multiply number of users by number of process executions by five seconds, that's sure to be more than two hours). It was harder for me, but it makes life easier for the users by increasing their efficiency.

Don't tell me I'm being selfish by writing good code - you're simply wrong.

Re:My code is ok

[obarel]

I'm glad to hear that you've found a place that lets you take the time to write code properly.

But even though you admit that you're lucky to be in a place like that, you still accuse others of working differently. For my employer, taking two days to solve something properly when it could have been solved in two hours "improperly" means losing business. If we can't promise, and deliver, products at extremely tight schedules, customers simply go to someone else. It doesn't matter that that someone else may give half-broken code that hardly works. All that matters is that we would lose a customer.

That's not to say that we write bad code on purpose (or at all). It just means that if we can save a little time development time by using a simple data structure, we're not going to implement the more complicated data structure, profile, optimise, and check if it's better. We'll just settle for what we have and get the product out of the door.

Again, this may sound terrible, but that's how most products are made. Not doing it that way means not doing it at all.

As for myself, I get a lot more out of my current work-place, because I see products with my name on them, than my previous work-place, where I could sit for two months and write perfect code that eventually wasn't used because we had no customers. If I could only find the perfect combination... but I heard it's quite rare - which is why you should consider yourself lucky.

Re:My code is ok

[HeronBlademaster]

No, I understand *that* completely... my complaint was coryking saying I should stop caring about "good code" and care about my paycheck instead.

Some places have strict deadlines, and I understand that. If that's the only reason you don't write "good code", then that's great, at least your heart is in the right place, right? But if you just plain don't care, that's what I have a problem with. Even on tight schedules it's occasionally possible to make things nice, but you won't if you don't care... it's *that* mindset that makes things harder for the rest of us.

Re:My code is ok

[coryking]

It is not that I don't care, it is just I've had to train myself not to care.

Nobody else but me takes any pleasure in good clean code, so I really shouldn't care much either. Honestly, there is very little business case for good clean code. You never see products that have "Now With 75% more clean code!" on their cover, do you? People dont pay money for that. They pay for "Now Solves 75% more Pain!". In other words, refactoring, rewriting, or optimizations are all cost centers that should be minimized. They do not directly add to a companies bottom line. New features do.

That isn't to say clean code is bad; create an unstable buggy app because your code sucks and you'll loose money. The trick is finding the minimal amount of "good clean code" you need to write to make your userbase happy. Anymore and you are wasting resources.

I'd argue if your paycheck is tied to some nebulous idea of "good code" is getting rewarded wrong. Your paycheck should depend on another, equally nebulous notion of "good user experience". I'd rather you write a nasty hack job that makes everybody smile when they use your application than a hard to use application that pisses everybody off, but has "good code" in it.

Good Code is code which creates a happy user. No other definition should be allowed.

Which code?

[Richard Steiner]

I've been writing code in various forms for 40 years as a hobbyist and almost 20 as a pro. That's a lot of code. :-)

There is code I write as a quick-n-dirty one-off for personal use, code I write with the intent of exposing it to outsiders, code I write which is a modification to someone else's work and style, and code I write which was mine from the beginning and (hopefully) somewhat more stable and elegant.

Some of the solutions I've up with over the years I think were elegant, some were hacks I made because I couldn't think of a better way, and some were/are probably poorly thought out.

As I gain experience in a given language/environment/platform, it's often interesting to go back and view my first attempts at writing code in that context. More often than not I see a LOT wrong with my initial attempts, but that is what experience is all about. :-)

Development Methodology

[inKubus]

Adopt a development methodology that defines what features will be developed and what features WILL NOT be developed. Now you have a place to put all those "great ideas" people have while you're still making the base product. You can also keep them in mind while making other modules, so you know you can make them later. This eliminates scope creep. It may not seem like a piece of paper will work, but as a society we all know the power of forms. Act like it's not your choice, that someone in management is making you use the methodology. No one will want to contradict anyone else so they will just accept it. And when it works, and you come in on-time and on-budget it will become part of the corporate culture.

Your deliverables (above) will be a part of your project charter. You will also include stuff like: a list of stakeholders, RISKS AND ASSUMPTIONS (such as a deadline not being met, etc.), testing, and of course "Success", which will be a list of metrics that define a successful product (ie: it can generate payroll checks, it can print report A, etc). Then, take your project charter (look it up on google) and put a bunch of lines on the bottom for you, the team and the management and the key users to sign off on. Do not start work until it gets signed off. Then make a copy for yourself and file the original with the project documentation. Work and complete all the features to be developed. At the end, take the project charter and make sure everything is fulfilled, then give it to the "customer" and have them sign off again for completion (after you demo the software).

Usually scope creep means poor project management, and as a developer you can't expect anyone else to do it. Just do it, you will be very thankful you did. Also, if it's a short project, try something called Quick-Kill project management. Large projects need a better methodology. I use one I made up that's based on the quick kill and some microsoft stuff, with some unix version control stuff, and oracle business process analysis stuff... Over time you will develop your own methodology and become a star senior programmer making $300,000 a year.

Have fun

Actually...

[RingDev]

One of my coworkers told me the other day he loved my new authentication and credentials system I used for the Data Access Layer. So much so that he snagged it and used it in another system that had similar authentication requirements.

Now, I've written a lot of bad code in my life, and I'd like to think a lot of good code to. I've seen beautiful code before. New attack vectors and amazing ways to approach problems I never would have though of. And each time I see those nuggets of perfection, I snag them. They get added to my pile of code samples for later use. Either in a straight copy or as a foundation of an idea that gets recoded, depending on license requirements.

Bad code is easy enough to deal with, bad design however... that will kill a project. Bad code can be hot fixed, cleaned up, or straight up replaced. But bad design will require new work from the ground up, getting the users and management to come back to the white board, verifying the requirements... If the system is not designed to meet the needs of the users, a memory leak won't be an issue because no one will ever use the software.

-Rick

Re:Actually...

[Bozdune]

This is exactly right. The code can be mediocre, it's the design that counts. Code can always be refactored if it's stupid or slow, but if the design is bad, you can be the Michelangelo of the coding world and your product will still suck.

Corollary: always document the design, not the code. As a software manager, nothing pisses me off more than tediously commented code with no overall design or statement of "here's what I'm trying to do." I don't really care how smart you are, or how clever your algorithm is. Most of the time, in fact, I'd rather that you just did something plain vanilla, because the 80-20 rule says that 80% of your code can be mediocre and stupid and nobody will care.

Re:Actually...

[billcopc]

Yep same boat here... I'm filling someone else's shoes, and every time I stumble upon yet another of his bastard projects, I get the urge to physically hunt him down and throttle the little shit, but then I realize it probably made sense to that one guy and he seemed quite prolific in his perverse ways. We just work very differently, and it's human nature that I consider my own technique superior... otherwise I'd have to admit that I suck and that's just not my style :)

Re:Actually...

[Hatta]

Bad code is easy enough to deal with, bad design however... that will kill a project. Bad code can be hot fixed, cleaned up, or straight up replaced. But bad design will require new work from the ground up

I keep hearing this, so my question is, how do you learn good design? There are any number of books out there teaching people how to program. It's relatively easy to get your head around the features of a language and crank out some small projects. But when the projects get bigger, I just don't know how to approach it. Do you just learn by trial and error?

Re:Actually...

[RingDev]

Pretty much. Learn from doing, and listen to those who have gone before.

My previous statement kinda mushed two aspects of design together. To clarify, there are two elements of design to consider. First is the application's design according to the needs the users have expressed (or intended to have expressed because what the ask for is seldom what they want). This part of the design you should have a lot of interaction with the users, project managers, DBA, etc... If this part of the design is screwed up, it is less the fault of the coder, and more the fault of the project manager, although a good senior programmer should be able to sit in these meetings and be able to guide the discussions in ways that better define the problems and solutions.

The other aspect is the actual function design of the code. There are a million ways to write code to do the exact same thing, so there are a lot of chances to do things poorly here. I've been coding these apps professionally for about 10 years now, and I can't even begin to surmise the things I've learned about design in those years, likewise I can hardly iterate the many more things that I have not learned ;) But I can share some tips to get you pointed on the right path for large systems.

1) Break it down. Everything is a matter of simple logical steps. Whether it is a Hello World app, or a navigation system for a Mars lander, break the logic down into as small of steps as require for you to normalize them. Someone else in the discussion brought this up. It is a balancing point though, if you write everything into function, it'll be harder to follow the flow of the program (especially when you get 4+ function calls deep in the stack, or introduce threading), but having 1 super long function won't be easy to navigate either. My general rule of thumb, is that if it is called multiple times, it gets a function. If it is entirely closed in nature, it gets a function (such as generating an empty data set). If it is a very wordy piece of code that refers to a simple construct, it gets a function (such as using reflection to pull out info).

2) Abstraction!!! GUI -> Business -> DAL -> Database. The DAL (Data Abstraction Layer) is critical. Once you wrap your head around the concept of using a DAL, the difficulty of large scale projects melts into those simple little logic problems you were just thinking up. There are many options available for use (MS's built in data server/source, nHibernate, etc...) and if you are new to the concept, an off the shelf system would be a good idea. You can write one yourself, but the amount of work that goes into writing one is significant, and because it is the foundation of your applications, making changes late in the game can require major refactoring throughout your code. Anyways, once you have a DAL, you can abstract all of the functional logic (in the business layer) from the database. Not only does this give you a lot of portability with your code, but it also makes maintenance easier as you don't have to battle with database code while working with the business functionality. And likewise for the GUI, it should be completely separated from the DAL and Database, relying on the Business layer for population. Again, this greatly simplifies maintenance, AND if your management ever wants to transition from Windows desktop apps to Web or Linux, you will only have to re-code the UI for the appropriate medium and use the same Business and Data layers.

I have seen a large number of developers come to learn about this design paradigm. Heck, just last month I was at a user group meeting where the presenter was a developer who had just cracked into this design on a recent project. Point being, new and old programmers alike are discovering how much power a DAL can give them. Both in speeding development, easing maintenance, and providing flexibility.

Personally I think design is one of the most important subjects that should be taught in schools. I was greatly disappointed when the subjec

Re:Actually...

[thegrassyknowl]

If the system is not designed to meet the needs of the users

If only the users knew what they wanted. I've worked in a few shops now and the one invariable truth about "customers" is that they never know what they want. They agree on something, go away and see Shiny Other Product (TM) and come back to change the requirements; usually more than once.

Depending on how long it takes them to come back you can end up with a design that is no longer applicable to their requirements and require fairly extensive rework.

All the time managers and sales people are out there wanking on about how they have the best programmers (well, they have me so it's not all wrong :p) and that these changes won't possibly effect the schedule at all.

It's no wonder that code is poorly designed and written. For all the formal theory good practice if management are continually moving the target at short notice every good programmer turns into a hacker... make it work yesterday, make it reliable in release 2 (which never comes).

Re:Actually...

[Anonymous Coward]

The book Code Complete 2 covers design to some extent. It's easy to read and well regarded.

For example, it covers maintainability. If one module accesses the internals of a second module, and the second module's internals change, then you might have to change the first module. The solution is to build an interface to the second module and avoid any extra work when its internals change.

That's pretty obvious, but it's the sort of thing covered. Check out the table of contents at Amazon (the detailed TOC after the short one).

Proud of my code?

[LGM95223]

I can't say that I'm proud of ALL my code. Sometimes a quicky-fix or work around is left in place because there is no time to clean it up. Also, there always seems to be fragments of abandoned code left in a project that gets forgoten. As for what to do . . . Well the problems are there mostly because of time restrictions and nobody is going to provide the time to repair them unless they cause real issues. And on the topic of drift! Sometimes it seems to me that the client has no idea of there own business rules and goals and will request the damnedest things just because they saw something similar somewhere and though it was cool!

Nope

[LoaTao]

"Have any developers here successfully lobbied their company to stop or cut back on 'cowboy coding' and adopt best practices? Has anyone convinced their superiors that the customer isn't always right and saying no once in awhile is the best course of action?" Not successfully. No.

Maybe you need a new line of work

[Anonymous Coward]

If you're openly aware that the quality of your work is poor, and you're constantly involved in projects that seemling 'drift' until clients run out of money, then maybe it's time you find a new profession.

Based on your statements I don't think you're cut-out to be a software developer.

Never about other people.

[SanityInAnarchy]

I was hired to work with someone who had been the sole person on this project for awhile. The first thing I did was start asking questions like "Why did you do it this way?" Sometimes, he had a good reason. Often, it was that he'd done it that way before he quite knew what he was doing.

But I was lucky -- we both pretty much agree on the "right way" to do something, and in cases where he had done something we both thought was brain-dead, I often had the time (while "learning the codebase") to refactor it. And that, I was proud of, particularly how fast I did it.

Now, I'm kind of in the same place -- I started out with a pattern that was kind of cool, and powerful, and when I was about halfway through implementing the classes that use that pattern, I realized how much code I was duplicating. Because I had to get it out the door, I just kept right on going, practically copy-and-pasting. This week, with any luck, I'll be able to take a few days back to clean that up.

So, in my own opinion, my own code will pretty much always look ugly before the first refactor. But I'm lucky, because I have a boss who programs himself, and thus understands the value of frequent refactoring and getting it right. And none of that really has anything to do with other people, they just have the advantage of being able to see where your code suck before you do (because they haven't had to live with it).

My Take...

[ericspinder]

People are apt to confuse arrogance and bluster with knowledge and ability.

The first step of a successful con artist is convincing you to distrust other people.

Management has a role in this too

[Anonymous Coward]

I've worked both as a manager and as a programmer, and -- although the programmers do have a significant impact on the quality of the code -- I feel that management's impact is even greater. Technically, even if the programmers all suck, it was ultimately a management decision to hire them (or to not hire enough developers, or to not train them if needed, or to re-assign them if required, or fire them if warranted). Sure, other factors may constrain what management can or can not do (budget, etc.), but... the buck stops somewhere, and that's usually at some manager's desk.

Now, I have seen programmers that wrote lousy code, but I've also seen a lot of really good, bright, motivated developers that were forced to compromise the quality of their code because they had no other choice. I remember one newly hired, enthusiastic jr. developer complaining about another developer's code (cutting and pasting, hacking, etc.), and then 6 months later he was resigned to the fact the he himself had to hack most of his code in order to meet the latest deadline..... this being a deadline that was already 50% shorter than the original developer estimate, grew larger due to "extra" customer committments (while keeping the "schedule" basically the same), and having to have worked most evenings and weekends for quite some time to "stay on schedule". There really wasn't much else that programmer could do, and he couldn't work any longer hours then he was already doing. If the schedule wasn't being met, then the developers were expected to make that time up and they weren't getting much sleep as it was.

And yes, the developer (not the manager) was still held responsible for the quality of the code afterwards. During one team meeting, a manager even stated "do whatever it takes, just get it done". So the developer did do whatever it took -- including design and coding shortcuts (and this was the developer's last resort: he tried working longer hours, but at some point couldn't keep it up). The developers even told management that they would need to take shortcuts to meet the deadline. Of course, the management critisized their designs and coding skills months afterwards.

Some of those managers believed that this aggressive scheduling was a "good thing" (after all, "...work expands to fill the amount of time given...", along with the reasoning that if they only give the developers 3 months to a 6 month project, then they have 3 months of buffer). Now, some managers were keen on actually changing things (as per some developers suggestions), but this turned out to really mean: "We're interested in changing things if it means that the developers change the way THEY do things. We're still going to keep managing things the same way we always did." That latter part was probably partially intentional, and partially unintentional (some really did want to change the way things were managed, but they themselves were too familiar with the old way of doing things to really change anything).

Now, I don't want to put too much blame on management (and some of my slant might be a bit biased, since the incidents are still fresh in my memory), but the point is that management can, and does, have a significant impact on the fate of the project and on the quality of the code being produced. Just because the developers are the actual ones writing the code, doesn't mean that they're solely responsible for the quality of that code.

As for improving the situation, I HAVE seen companies make changes for the better when those changes were management-driven, and driven by a manager that knew what changes to make and believed in them. When the changes were initiated by the developers, they tended not to really get adopted -- mostly because management didn't really embrace the new way of doing things. Not that that's a reason to remain quiet if you're a developer: your best bet may be to talk with management about why things aren't working well under the current system, and why things need to change (along wi

Occasionally I ...

[kcdoodle]

Once in a while I take a small change and tell the client/boss/myself that it is a really BIG change.

Then I go through a totally re-write the code from end-to-end. I look for unused sections, variables, etc. I re-order all the logic so that it is logical. Then I test for the necessary period of time.

Since most of the code is already written, I start by writing out the business rules and I make the order of the code follow the order of the business rules, more-or-less. I put ALL of the business rules into the code as comments. I also send the rules to the client/boss/myself/others.

Doing this just once a year, on each critical section of code actually saves me much more time than the initial investment, so everyone wins.

Re:Occasionally I ...

[Jaime2]

Until there is a small bug in one of your re-writes and a maintenance programmer sees the change to feature X was made on a project designed to fix feature Y.

Where I work risk analysis is a big deal. If the PMs knew I was changing that much stuff, they would rightly throw a fit and ask for two extra months of testing.

If you are going to to do a re-write to decrease maintenance needs in the future, sell the project as such. Otherwise the wrong person is in charge. Programmers shouldn't be sneaking in pet projects on the customer's (or the business unit's) dime.

Sorry, I have to bite about this.

[Fross]

I am one of those people who likes lots of code. So much so that I've developed a style, similar to how I used to code 68k assembler, of running comments down a second column (usually 40-60 characters in) that describes what is going on. After all, it doesn't interrupt the flow of the code, and if you're editing Java on an 80-column fixed-width interface, you're doing it wrong to begin with. I wouldn't say I comment every line, probably one in every 3. However, this gripe with over-commenting is fundamentally flawed:

and I've met people who won't even look at code unless every single line is commented telling them precisely what it does, so "int i = a + 2;" has to have a comment above it saying "// create a signed 32-bit integer variable, i, and assign it two more than the value of a".

Why on earth would you write a comment like that? That is ridiculous. However, the line DOES need a comment. It's declaring a variable with a non-descriptive name and doing something specific with it. Now, the comment should do something like say what the variable is used for, if it's non-obvious. In this case, "int i" is usually used for loops, so it doesn't need a comment unless it's *not* used for loops. :) However, if it was being used in a loop, why is it being set to a+2? Is a some sort of offset in an array? Is it a user-entered value? THIS is what the comments will illustrate, eg:

int i = a + 2; // skip the first two elements in the loop as they contain other data

or

int i = a + 2; // user input will be off by 2 because of (strange reason here)

writing comments like "initialise variable" is useless, but thinking that may be all there is shows a misunderstanding about how comments work.

You can assume the person reading your code is a programmer, familiar with the language used, and able to follow general program flow. However, he may not be familiar with the rest of the system, nor with any specific tricks you may use[1]. Comments should be like a director's commentary on the code, pointing out what may not be obvious, and giving the bigger picture - the reason why a specific variable is used a certain way, or what a messy few lines of code may be achieving, eg: // now split the input into an array and parse ready to give to the file handler
(horrible loop declaration here)
(even more horrible regex here)
(custom function calling here)

It's said comments are like sex - even when they're bad, they're still pretty good. I'm pretty sure I've never spent 3 hours trying to work out how to get THAT to work, though!

[1] eg, I use a relatively uncommon trick in Java doing string comparisons of if(!"blah".equals(myString)) because it can't fail on the null pointer check that if(!myString.equals("blah")) can. A simple example, but something more complicated will save someone time if it just has a quick comment next to it saying what that section of code is achieving.

Re:Sorry, I have to bite about this.

[SilentBob0727]

I think we're saying essentially the same thing. I'm arguing for better commenting and learning what kinds of comments are unnecessary.

I'm griping about comments that triple the size of the source code and disrupt the code's readability, yet say nothing that can't be discerned immediately from the code.

Comments should describe "what" in only very high-level terms, which is why "what" comments are better suited to method and class level. Beyond that, they should primarily talk about "why", and to a lesser extent, "how" (if the how isn't plainly obvious).

I think the "if in doubt, comment" suggestion is actually bad advice. It leaves people thinking, "God, I really should write a comment here, but I just don't know what would make this line any clearer." Crap like "// create an integer and add two to it" comes about as a result.

>> It's said comments are like sex - even when they're bad, they're still pretty good.

I would suggest over-commenting is like having sex while watching a porno -- great at first but after a while it becomes a distraction. When comments are well written, it really becomes a case where less is more.

Re:Sorry, I have to bite about this.

[tieTYT]

If I feel a few lines of code are confusing I think of how I would comment it. I then use this comment to come up with a name of a method instead. If something can sufficiently be explained in a method name, the method name is preferred. Comments have their evil side. If you have a lot of comments on some code and you refactor the code, it's likely that the comments are not completely accurate anymore. Now, if you want everything to be synced, you have to modify code AND comments. If you don't keep your code synced with your comments, your comments are not only worthless but harmful. I've seen comments like this:

int i = i + 3; //add 2 to i

When you see something like this, all other comments have instantly been discredited and useless. Maybe you're thinking, "The same thing can happen with method names". And you're absolutely correct. But, it's much less effort to rename a method name, especially with refactoring tools built into IDEs.

Re:Sorry, I have to bite about this.

[batquux]

...if you're editing Java, you're doing it wrong to begin with.

Fixed that for you.

Re:Sorry, I have to bite about this.

[macrom]

It's said comments are like sex - even when they're bad, they're still pretty good.

No, programming is like sex. Make one mistake and you end up supporting it the rest of your life.

Re:Sorry, I have to bite about this.

[david_thornley]

It's said comments are like sex - even when they're bad, they're still pretty good.

I see you haven't met my first wife.

The Difference Between Programmers....

[coaxial]

The difference between a competent and an incompetent programmer is that an incompetent programmer thinks his/her crap code is the best, while a a competent programmer knows that his/her code is crap.

Sure this is funny, but there's an underlying truth to this. Someone that knows what he/she is doing, knows all the ways the code could fail and all the the checks and exceptions that should be there that is isn't, and how the assumptions of the underlying algorithm may not be strictly guaranteed, and is just waiting for the code to break. Someone that doesn't know what his/she is doing thinks everything is great since it passed his/her incomplete unit test. Or to put it another way: Ignorance is bliss.

Re:The Difference Between Programmers....

[kcdoodle]

GOOD POST (I wish I had some mod points).

This is also true of general competence and incompetence...

People who are truly incompetent in their field have no clue of what real competence is (in that field). Those people tend to believe that they are the only competent people and that everyone else is out to get them.

Only those who are actually competent can see their own shortcomings and try to overcome them.

This is not my theory, someone more competent than me pointed it out to me, and I have held it as a truth ever since.

Limited resources

[jbeaupre]

I think the code to be most proud of is when it's written to work with limited resources. Who isn't impressed by the assembly coders who crammed fast, fully functioning programs into some minuscule space? Sadly, fast processors and gobs of memory have made things too easy. Now you don't have to think several steps ahead. It's still possible to be proud of inventing new algorithms (i.e. shaders, bittorrent, etc). But the programs themselves are much more pedestrian.

Quality of code versus execution

[caywen]

In my experience, I find that quality of code versus quality of execution begins closely correlated when the bulk of code belongs to a smaller set of talented engineers. As soon as you bring in third party API's and less talented engineers, the relation becomes inverted - stability and performance often begins to depend on the amount of hackery one does to get around shortcomings outside your control. Not saying this is always the case, just is often the case.

test first

[Surt]

You should consider adopting test first development, this will have numerous advantages for your situation:

"It is buggy, slow, fragile, and a nightmare to maintain."

1) Test first code isn't buggy. It has tests that prove the correctness for all important cases.
2) Test first code isn't fragile. It has tests that allow easy refactoring without risk of unknowingly breaking an important use case.
3) Test first code isn't a nightmare to maintain, for the same reason as #2. The tests also help to document the use cases in a way that comments frequently fail to do.

It won't do anything about slow, unless your test cases help to specify minimum performance levels. In which case it can solve that problem too.

As a coding practice, it has one main additional advantage: it has good empirical results, and that's sellable to management. Management likes good practices, particularly one you can sell as cutting costs in qa through automation.

Why It Sucks to be an In House Programmer

[tuzo]

Interestingly, Joel On Software posted recently about why it sucks to be an in house programmer: http://www.joelonsoftware.com/items/2007/12/04.html

The number one reason: "You never get to do things the right way". So maybe some of the blame is circumstances?

Your manager works for you.

[kwerle]

I also cut me teeth on the IIe.

It is possible you are just not a very good programmer. But maybe you are, and you're being "poorly managed". Being poorly managed is your fault.
Here is a list of your responsibilities:
Implement what the customer needs.
Implement what the customer wants.
Do what your manager needs (distant 3rd).
Do what your manager wants.

Here is a list of your manager's responsibilities:
Make it clear to you what you are supposed to be working on.
Make it possible to do what you're supposed to do.
Make it easy to do what you're supposed to do.

Your manager works for you. If she asks you to do something you should not be doing, don't do it. If he is not making it possible/easy for you to do what you need to do, complain. Learn the word "no." Say it over and over. If you are the [only] programmer, or you are the team lead, you know what is best for the project. Explain how and why it is best. Be understanding, but be firm.

It is important to be honest and clear very early in the process. If something can't be done [in some period of time], you have to say so. Better if you understand what they want and see if you can do something similar in the timeline suggested, in addition to explaining how long it will take "their way" - that's "being flexible". Doing something the wrong way (most of the time) or agreeing to something that can not be done in the time given is not "being reasonable", it is being harmful to the project.

My notion is that 90% of the work done on any project will be after it is "complete." I don't know where I picked that up, exactly (in some college course, long ago), but it seems like a reasonable attitude to approach a project with. And if I'm going to spent 9 times the effort maintaining the project as I spent writing it, I sure as hell want it to be easy to maintain.

legacy

[suitti]

My last two projects have been to babysit and sun down legacy systems. These were written in Perl, are web & database based, were written over a period of about ten years by multiple people, had no development system (all changes are made in production), and are each at least a half million lines of code.

One such system has two very different kinds of programmers. One kind produces very small, tight, elegant code. Each line may be complex, but there aren't very many of them. Another kind generally codes for conceptually easier tasks, and has a verbose style. Individual lines are trivial assignments, but there are sometimes thousands of them.

The elegant code is MUCH more difficult to debug. It's also, generally, broken much less often. The verbose code is generally very easy to fix.

But i've gotten an appreciation for other ways to do things. And, there aren't nearly as many of us 'elegant coders' out there for replacement. But i still don't see how some apps can be accomplished at all without us. This appears to be language, library and tool independent. Fred Brooks seems to have something to say about this.

I'm firmly in the realm of 'elegant coder' myself. My favorite piece of late is 750 lines of very dense code involving a seven dimensional hash (but sometimes six - it varies) with dynamic indexes. It replaces a 25,000 line chunk that had to be changed every year. The new bit never needs change. However, despite ample documentation and three tutorials, i was unsuccessful in showing the new team how it worked. The new system has designed this bit out completely.

One thing about both projects is that the employer either started a project to replace them, or actually replaced them. In both cases, it was an incredible amount of work and expense to do this. Millions of dollars. It would have been both cheaper and better to fix their problems, and update their user interfaces. At least, once an appropriate programmer was found. Oddly, we have at least two on our current team.

Oh, yes. The replacement projects went over budget and were late by at least a factor of two. Much more, if you consider that something like half of the functionality was removed. And there seems to be one chunk that the new team doesn't seem to be able to deliver. Perhaps the new team needs an elegant coder.

Re:legacy

[xant]

It's just that your definition of "elegant" is wrong.

See the zen of Python.

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

Python is a language designed with the goal of leading programmers to write more readable code. It's still possible to write dense, terse Python code, but the language itself with its significant whitespace and assignments as statements makes this harder. It's easy to tell well-written "elegant" Python code from the other kind.. when you're reading it, you can find any variable name either in an import or on the left hand side of an assignment.

But what's possible to do in Python is possible in almost any language.

Your readable code doesn't have to be inefficient or information-sparse. Use your language's idioms to achieve expressiveness .. your language's gurus have probably come up with the "right" way to express something a long time ago, and practitioners of the language will know how to read it in a glance. For example, this old gem in Python:

a,b = b,a

This is an extremely readable and yet information-dense idiom. Similarly, most Pythonistas know about this one to detangle a zipped list:

ll = [[1,'a'], [2,'b'], [3,'c']]
zip(*ll)[1] ## returns ['a','b','c']

Not quite as readable to someone who doesn't know Python very well, but extremely information dense.. and if you understand the language's idioms, you don't have to think about what that does very hard.

The point is not that Python is such a great language. All languages have these nifty idioms once you learn the language. Learning the language's idioms very well gives you terse, expressive, and efficient code that remains readable.

Re:legacy

[suitti]

ll = [[1,'a'], [2,'b'], [3,'c']]
zip(*ll)[1] ## returns ['a','b','c']

actually returns:
('a', 'b', 'c')

I've not gotten far enough into Python to have any clue why. That means that the barrier to entry is fairly high. If this is a standard idiom, then the next question is naturally, What problem does this solve?

It sort of reminds one of regular expressions.

Go agile

[beef3k]

You need to look into agile development practices
Improve the team, improve the code and let the customer INCREMENTALLY decide what functionality to put into their product.
The customer is never wrong - it's just that their requirements change over time and both you and the customer need to embrace and capitalize on that rather than constantly fight it and end up delivering a product that neither you or the customer are happy about.

Perfectionist

[BackBox]

I spend so much time on thinking design, using best practices and thinking names of my variables to making the code more efficient which is sometimes even irrelevant to the project/problem but since its my passion so I'm the slowest programmer around I think :/ But I am proud of my code! B)

Re:Perfectionist

[Emerger]

Maybe you think that you are the slowest programmer. I used to think so too, because of the same attitude that you have. But at some point somebody from QA told me that they love testing my code, because it has far less bugs than anybody else on the team and if they find a bug I actually fix it the first time and then without introducing 10 new bugs. The rest of the team has lists and lists of bugs, because most of them are cowboy coders. The biggest cowboy coder also has the reputation for quickly banging out new stuff, but he is driving the project manager nuts with all his bugs, which constantly causes us to miss deadlines.

Does it work?

[ducomputergeek]

There is an old quote in the PERL world: there is more than one right way to do it.

The only formal programming course I ever had was a VB class in college (needed a "computer credit and I didn't know VB). Everything else I've learned from looking, reading, and writing/rewriting code till it worked.

Re:Does it work?

[Chysn]

> There is an old quote in the PERL world: there is more than one right way to do it.

        Actually, it's "There is more than one way to do it." I don't think anyone can guarantee that there's more than one RIGHT way to do it.

Not quite true

[Moraelin]

Come on. When was the last time you had anything good to say about anybody else's code? Ever? All programmers say all other programmers are incompetent. And typically, management believes us.

Not quite true. I can think of a few people whose code gave me no reason for complaints. To pick just two extremes out of the pool:

- one of them is pretty much the pragmatic programmer prototype. He'll (also) apply some pattern only if it's needed, not because it would be fun to have it on the resume. Sometimes a switch block with 10 cases is really all you need, you know? His programs tend to be compact, work and be actually fairly easy to get the hang of.

- one of them is, well, pretty much the opposite. His programs tend to be a lot larger than they need to be, and have layers upon layers of patterns even to print "Hello World". With some reflection thrown in for good measure. Strangely enough, though, they _are_ well organized, and you can fairly easily find the class that processes a given event or command... or the singleton factory that supplies it, or the manager class it's registered with, or...

Are they perfect according to my tastes? Nope. But I can nevertheless tell good code when I see it, even if it's not perfect. And say it.

On the other hand, at the other end of the spectrum, I've had to deal with pieces of code which were truly atrocious. E.g., one particular program not only raped all best practices known to mankind, but also was living illustration of half the techniques from How to write unmaintainable code. Literally. It even had stuff like the using people's first names for variables, in addition to the more mundane techniques like mere undescriptive names, obfuscated flow, heavy use of global variables, non-obvious side-effects to those variables, or methods which can also do some 2-3 other unrelated things if called with the right parameters. And I don't mean just side-effects or cramming more functionality in one call than expected. I mean stuff like the class which should have normally sent an email, could render and print a PDF _instead_ of sending one email, or update the contract in the database instead. And for bonus points, not even determined by parameters, but by the contents of those global variables. But, again, the nicest touch was finding uninformative variable names like Pete and Eve in the very first class I opened.

Basically IMHO lumping it all into one everything-is-the-same "all programmers hate each others' code" pool doesn't do it justice, and paints a misleading image. _Some_ may be just nitpicking about the style, but some code is genuinely evil stuff that should be buried at crossroads with a stake through its chest.

Read Code Complete

[Anonymous Coward]

Code Complete is a must read in that matter.

How to be more proud more often

[inonit]

At least for me, the key is to feel like I have time. Not even to have time, but to feel as though I do. Then you go the extra mile to make each piece easier to use, easier to understand, and simpler.

You actually get done earlier, too, so you usually don't have to actually have time to do this. But I still haven't managed to convince my brain to ignore time pressure when I'm in a hurry, so I still churn out less elegant, buggy stuff that takes longer to write when I'm under time pressure.

You are, and here's why

[JoeCommodore]

I am downright embarrassed by the quality of my code. It is buggy, slow, fragile, and a nightmare to maintain.

That above statement is holding you back, Everybody's code sucks in one way or another, my code sucks in some ways I do things but there are things I do that make it worth the effort. And I know my next bit will be better, I know how to do what I've done and I have better iseas on what to do next. Also in that tangle of code I bet there are things you ARE proud of, did you pull of some nice intuitive user interface? Or maybe you made that page of data look real professional, don't overlook your good skills.

...More importantly, what if anything are you planning to do about it? I enjoy programming and have from a young age (cut my teeth on BASIC on an Apple IIe). I have worked for companies large and small in a variety of languages and platforms.

I got my start in BASIC (on the Commodore PET, then on the 3.5K VIC) I still write BASIC programs for my Commodores in my collection in BASIC. I also have worked on many different programs - databases, data conversion, graphics, games, sound, etc. all are good experiences on how to do or not do things. Every time I do something new I take the wisdom of what I did before and the ideas I have learned since and integrate them, Along the way I pick up some style tips, or a better method to do something, those go in the next project or future rewrite. I liken good programming to woodwork you can make a lot of functional pieces, each one getting better then the last as you work toward masterworks.

Sadly the one constant in my career is that I am assigned to projects that drift, seemingly aimlessly, from inception to a point where the client runs out of funding. Have any developers here successfully lobbied their company to stop or cut back on 'cowboy coding' and adopt best practices?

Part of that can be alleviated by good coding but it sounds like your is more a communications issue, where the customer is going back to some base function and making significant changes. Also, again from the filed project learn from your mistakes and the knowledge you gained from the experience, paraphrasing Thomas Edison, you may not have learned to make a light bulb but you learned many ways not to.

Has anyone convinced their superiors that the customer isn't always right and saying no once in awhile is the best course of action?

Communication also; start with encouraging some realistic milestones not everything in one fail swoop, if it is something 'completely new' encourage the customer to start off small (and inexpensive) and build from there as you both learn the system and all the data/customer needs. You probably will need to rewrite, but you will not be rewriting something you were unsure of in the first place and still are.

Also thinking on this, maybe part is the platform you are developing on; some development languages/tools are a pain to try to do advanced stuff with, others are just not well suited or specific things. Ask yourself: "Am I struggling on the project or the platform I'm developing in?"

Changes over time.

[Anonymous Coward]

Long term, I'm never proud of my code.

There's been a steady increase in the amount of time it takes until I stop being proud of my code, though. Several years ago, it used to be that I already couldn't stand to work with my code after 2-3 months. Two projects ago though, it took me a year and a half before I first started thinking the code sucked, and then I only needed to rewrite a single component before I was happy with it again. The two projects since are still quite perfect.

I have no illusions though. As customer requests keep coming in, and the design reaches the boundaries of its flexibility, the code will slowly become less and less suitable for the purpose to which it's being put, and any pride in it all will vanish. Yet, I'll keep learning, and setting up my code ever better (without falling in the trap of over-abstracting), and the useful lifetime of it all will keep increasing.

If that process ever stops, it'll be time to start looking for a new job.

I've accepted it

[Anonymous Coward]

The problem is compounded by programmers like myself who have gone from working for a COTS software company to working as a programmer for a non-software company. In the past I would strive for creating the "elegant" solution. But now if I decide to spend time refactoring code, I seeing the people who churn out code the fastest - regardless of quality or maintainability - being rewarded with the best work. Screw that! I've given up... now when I edit someone else's code I follow the same low standards they did.

Ah, kids these days...

[Moraelin]

Ah, kids these days... so easily impressed.

I remember one piece of code that makes even that seem tame. Assembly, mind you, back in the 386 days.

Someone had calculated something as a 4 byte float, then took it as a 32-bit integer, swapped the higher and lower 16-bit words, wrote it into a memory location at the start of a function, and then actually jumped to that location. I.e., he actually executed that result. That was actually in the (uncommented) assembly source code, mind you, not some accidentally disasssembling a piece of the data segment and discovering that it makes no sense.

To this day, I have no clue what that did. Awestruck is putting it mildly.

Re:Ah, kids these days...

[LiquidCoooled]

Lots of fun can be had with self modifying ASM code, and the most likely reason why he used a 32bit float to do a calculation then pushed the result back onto the code was for unsigned arithmetic over 15bit (a 32bit float stores the integer portion for ~23 bits IIRC). If you try it with ints you end up jumping to the wrong location.

Its a shame I moved away from assembly when I came to the PC, but at that time (which incidentally was about the 386/486 changeover) the architecture was so much different from the 68k I was used to.

Re:Ah, kids these days...

[Moraelin]

No, you don't understand. He didn't calculate the address to jump to. _That_ I could quite easily understand, actually. He calculated the code to execute. I thought I was teh uber assembly guru, but just realizing that that's what's happening made me go cross eyed :P

Re:Ah, kids these days...

[LiquidCoooled]

Sounds cool, the guy isn't called Mel by any chance is he?

Re:Ah, kids these days...

[Moraelin]

Heh. Well, no. It was decades after the days of Mel too, as far as I can tell. But I guess there are many paths to enlightenment and many Buddhas/prophets/avatars/etc one can stumble upon and be humbled by their wisdom. Mine was thousands of miles away and decades after, but the effect was the same ;)

Re:Ah, kids these days...

[KlaymenDK]

Posting that link was my immediate thought, too. I am so in awe of Mel, a little freaked out by him, and so very happy I don't have "a Mel" in my department. ;)

A lot of my code is sloppy

[krunk7]

Over the years I've noticed a trend within my jobs. Often I'm "the technology guy", yes that's singular. For example, I'm currently working in a research lab as "the tech guy". I'm often never given the time or resources to write truly clean code. This is usually due to three situations, though all are similar. Let me explain:

Situation one is when a need is perceived and a fix is desired *now*. I'm asked to implement a fix, then constantly asked if it's done yet. The moment I can give an example of it somewhat working, I'm pulled off the project with the declaration of "it's good enough". The code is usually barely out of the prototype stage. Subsequent fixes to the code are done sporadically and in between more pressing needs. Again with pressure on quickness rather then robustness.

Situation two is a result of gross under estimation of the depth of the project. Such as "Hey, can you implement a usb driver for this new device we have that isn't supported. We also need a gui front end for it. Oh, we have two weeks." I work solo btw and have never written a device driver before.

Situation three is a lack of appreciation for specialization within the technology field. I find this one very surprising being that I work amidst individuals whose careers are defined by their specialization. For example, I'm given a project of the utmost priority to back port/port an application in a language I've never seen before. Or perhaps asked to spec out an enterprise level backup system. Since I'm considered "the computer guy", my "expertise" is viewed to encompass network engineering, hardware design, all languages ever conceived, and the ever pervasive "helpdesk" type tasks.

It makes for an interesting and dynamic work environment, but also leads to less then ideal code and many projects I would consider incomplete.

Sounds like dumb+lazy to me

[giafly]

... some of the ugly code in any implementation is to get around bugs in the development system, programs it interfaces with or even the O.S. itself. The inexperienced programmer only sees the ugliness of the end result, they assume that the original programmer was dumb/lazy/old-fashioned...

Damn right. This is a classic case where comments are absolutely essential, otherwise anyone trying to change the code will break it.

I would have told it like this.

[Anonymous Coward]

Q: How many developers does it take to change a lightbulb?

A: None. It's a hardware problem.

My code works fine :)

[TheLink]

If your code is so crap and you can't seem to get better at it, maybe you should get a new job where you can do work which you are reasonably proud of. Do you really want to be like those CEOs who do a crap job and get paid for making everyone else suffer?

I'm definitely not the best coder out there, but wow there sure are plenty worse - the benefits of open source is you get to see how crap (or good) other people's code is compared to yours :).

I don't like some of the stuff I had to write in the style of someone else's code - fixes/changes to old (and often very crappy code). Sometimes you can only just make things less crappy - if you try to remove all the crappy bits you end up having to rewrite everything, but nobody will reward you for that and you'll get in trouble for anything they don't like.

The stuff I write from scratch for production usually has very few bugs. I don't churn out code rapidly like others, but my stuff tends to work and keep working. I have a fair bit of experience in IT security and breaking/abusing stuff, so I write stuff accordingly.

I'm also really lazy, so I'd rather get things right first or second go so that I can waste time on slashdot and other stuff :).

Typically the "problem reports" I get end up being due to something else.

Recent examples:

Someone thought there was a prob with one of my programs, so we looked, then got another colleague to look and conclusion was it was likely to be a bug in Linux, perl or hardware (in order of likelihood). Somehow after a restart of apache, Linux/netstat claimed that my program was listening on IPv6 :::* port 80, and unless we're all wrong here there's no way my program would do that - the socket binds are all IPv4 only (pretty easy to check :) ) only done at the start and both the program and apache were running fine before. The program was started days before and was still running at the time apache was restarted (and failed to rebind to 80).

Then there was a reported problem with the dhcp server I wrote. I initially thought it was my bug. My dhcpd sends IP broadcasts in ethernet broadcast frames as replies to Vista (as default vista wants) which worked fine everywhere else (unlike some versions of ISC's dhcpd. Nyah! ;) ). At some places Vista machines could not get an IP when behind some network devices. Turns out to get things working the dhcp server had to send an IP broadcast but ethernet unicast.

I thought, "oops my fault, should have done that from the start" (I actually did have a comment there wondering whether I should use unicast ethernet replies- seemed more efficient ), but after rereading the RFC2131 and doing some thinking (it's not explicit that broadcast = IP AND layer2 broadcast, but reasonable enough assumption right?), conclusion was the way I originally did stuff was RFC compliant, and it was the network device that was misbehaving - it should behave like a switch/hub and pass the layer 2 broadcast frames. So the fix will be a "configurable workaround" thingy. Easier to "fix" my dhcpd than to fix a few hundred network devices made by some other vendor.

Oh well side benefit is my dhcpd can now be configured to reduce dhcp broadcast traffic due to vista. I doubt we'll encounter that many vista machines though ;).

As for the customer not always being right, well that's the company's fault, and fault of the person handling the customer.

The customer knows _vaguely_ what they want, you have to help them figure out what they really want. Take building a custom house as an example.

The Architect has to sit with the customers and say things like "If you want an olympic size pool, you can't have parking space for 4 SUVs unless you're willing to fork out a lot more money, and it'll take at least 3 months longer, and we'll probably do things this way".

Thing is most companies don't have people who 1) understand that, and 2) can actual

Excuse me if I'm rambling, but...

[djasbestos]

I fully agree. I inherited a LOT of uncommented and shittily commented code, and it is a royal PITA to figure out WHY it is doing what it is doing (which was basically your point). On the other hand, at least with crappy comments, there is occasionally a nugget of useful information...I despise the comment-free code more, but the code itself also looks like it was designed by someone on an acid trip.

So yes, comments should say WHY more than WHAT (specifically) a line or block of code does. A short narrative is usually the most helpful, ime. Basic description of what the method (or even a crucial line if it's the least bit unconventional or otherwise unintuitive) does (in bird's-eye-view terms / how you would explain it to a non-programmer), and WHY it is doing it if that purpose isn't obvious from WHAT.

And I also say (most of) my predecessors' code sucks, but in this case, it does. There was one guy who seemed to have a decent idea of what he was doing, and I think he got burnt out by the complete buffoon of an "IT Manager" they had at the time (hurray cronyism! He still works here in his own project group because he's friends with the big boss). But the other guys...one would have actual end-user visible error messages like "the stupid polack messed up again", and had one of Shakespeare's plays in its entirety linked on one of the maintenance web sites. The other guy consistently set up SQL accounts with "password" and sysadmin privileges (I've gotten it secured now, but it's causing quite a bit of havoc for some users). Crazy and stupid, respectively. Then we have a contractor (still with us, hopefully not much longer)...who is arrogant AND stupid (with coding, anyways...quite manipulative with the non-technical people who control his paycheck). He implements concepts and technologies that he does not understand in completely useless and excessively complicated ways. He also has a big problem with turnover of his underlings, resulting in even crappier code. The rest of us want to completely scrap his project because it's so bad (the aforementioned "acid trip code"). But you know what they say: "CONTRACTING: if you aren't part of the solution, there's good money to be made in prolonging the problem."

I am lazy: I make sure it works before it goes out, and I write it so the user can configure it to do what they need without having to bother me to do hard code changes, recompile, and redeploy. I've already got enough of that with existing code I've not yet had time to rewrite.

So, in short, if you are neither crazy nor stupid, your code probably won't suck that bad. Every time I'm skeptical of my own code, I just look at the code I am maintaining and replacing. I simply remind myself: mine actually works. I wrote them from start to finish, so the code is consistent. My boss can look at it and understand what it's doing with his experience with older languages and teething knowledge of .NET. And the other programmers whose code does NOT suck (separate project group) have given me positive feedback on what they've seen of mine. A limited degree of self-doubt is good for keeping you honest with the quality of your work, but don't worry about it TOO much.

Variform.

[andr0meda]

Code is organic by nature, because humans tend to evolve things in an organic way. As such, keeping code in good health requires a lot of attention, which costs money. Automatic refactoring tools may be evil for VCSes, but they are the most valuable tools we have to keep code in shape.

Code is also (usually) a collaborative exercise, bringing lots of different ideas and principles to the table. That is why software "Patterns" are so valuable, so that people can communicate about code in a structured and compatible way.

Code is something that no one has time for. Visual programming 4th generation languages and Functional Programming are ways to get the job done faster, easier and with less of a hassle, and more docs to read. Both are still way off the target goal, but in the last few years some nice tools have developed.

Code is bound to run on something, and that "something" is changing all the time. You can't check in and label your machine in your VCS, which means you have to try to make it run as good as one can within certain constraints. This is where the virtual machine has helped make a lot of progress.

Code will always be needed, though the format and logic behind it will keep changing and morphing. The battles between speed and memory, cost and ownership, data or function, abstraction or generalization, top-down or bottom-up, these battles will always exist. In the end, writing an executable program that does the job is just a very sophisticated search in a search-space that we still need to define better.

That said, check out Variform by kewlers for no apparent good reason, other than to look at code as an artform. Ps. There's tons more where that came from.

Cheers!

legalistic confrontation quenches creative effort

[MellowTigger]

Yes. Yes, I am proud of my code, even some of the awful stuff when I consider the circumstances in which it was written.

I think that part of the problem these days (rather than part of the solution that it is touted to be) is analysis. Some of the best work I've ever done had minimal analysis. It was the result of hand-drawn scribbles from a customer (internal, Billing Department honcho) discussed during an informal talk about the project. Data/timing issues and customer must-haves were thought out (and scribbled by me on my own notepad). "Unprofessional", by most any standard. But it was a very reliable system for years, and it was internally documented to perfection. Customer kept their own copy of the descriptions they created (and understood), and programmer (me) kept his own copy of the descriptions in the code commentary itself. Meshing the two interpretations was the responsibility of the PEOPLE involved, not the documentation PROCESS. Any last-minute show-stoppers were avoided by occasionally showcasing the test environment to the customer prior to final q/a exams.

<soapbox>
After nearly two decades in the tech business, I still do NOT understand why "documentation" (the usual kind) is considered a helpful tool. That stuff is written in legalese that is not the first language of EITHER the programmer OR the customer. How could it benefit anyone to write/read specifications in a foreign language? It would be like insisting that customers write out their specs in COBOL (more English-like than most doc formats I've seen). It makes no sense to me.

I'm of the opinion that customers should be responsible for writing out the test scenarios that they want to use for verifying the product. They do their own quality assurance, in other words. It's up to the programmer to create a system that fits those tests. Customers write out their test scenarios In Their Own Language that they're comfortable with. Programmers are smart folk, by and large. What they can't understand immediately, they're inquisitive enough to ask someone to explain it to them. Everyone knows up front that if something doesn't work, it's the programmer's fault. For not asking the right questions, for not examining the right interfaces, for not doing proper module testing, for all of it. (Well, short of actually writing the final test scenarios, which is the responsibility of the people knowledgeable about the process being automated. That's not the programmer.)

It was a great system that worked wonderfully for both me and my customers. It produced what I still think is good code.

On the other hand, when that same environment went ISO certified, it all came screeching to a halt. Massive delays, useless finger-pointing over documentation errors, people involved who had no understanding of either programming or the process being automated. In essence, legalization of the creative process... introducing mandatory opposition where there had previously been cooperation. Just like a legal court, the PROCESS is designed so that BLAME (codeword: "responsibility") can be determined with certainty. No creative process should have to endure such insult.
</soapbox>

No, wait...

<soapbox>
It's incredible that anyone would think documentation could answer the question, "How long will it take you to do something that you've never done before." Yet the entire industry still seems bent on producing these estimates that are, as a rule, wrong.
</soapbox>

Software engineering culture

[Anonymous Coward]

I think that most developers already experienced the same (or will experience it at some point in their professional life). The best advice I can give you is to buy Creating a Software Engineering Culture by Wieger. You should definitely buy two copies. You keep one and you have a nice Christmas present for your boss. The message will be straightforward and unambiguous.

If he is not a total incompetent with a MBA (sorry dudes), he will read it and realize that his company has implemented a lot of the Culture-Killer things from the book!

Re:The normal response of an inexperienced program

[B1]

Sometimes, you really do inherit sloppy code... stuff that doesn't anticipate failures, or attempt any kind of error handling or recovery.

Sometimes, the code wasn't written with the mindset of how things *should* be done. Sometimes, the code was hurriedly slapped together by somebody who didn't anticipate the ways that things could fail (e.g. malloc() failure, disk full, database connection failure, etc). Sometimes, it's code that was written poorly because the developer didn't know of a nice standard best-practices way to do it, didn't care to figure it out, or dismissed it out of hand because they didn't get it.

Other times, you run into code where the developer gets fancy in an attempt to shave every last cycle out of their code (especially when the application isn't even CPU bound to begin with). Sometimes, developers like to do it the hard way just to show off how smart they are.

Finally, sometimes the code you inherit is truly spaghetti code. Some of my favorites:

• dead code that is never executed
  
• while() loops that can become endless loops in non-obvious ways
  
• function calls that take 15 arguments
  
• function calls that nest 15 layers deep, and require you to hunt through source code scattered all over the filesystem (e.g. /usr/include/my_code/object_list.c)
  
• To go with the above, using #include to reference functions in another C file (e.g. #include "object_list.c"
  
• unnecessarily cryptic variable names
  
• using macros excessively, especially when the macro definition is more complex than the code it replaces.
  

my general rule

[Anonymous Coward]

my experience has been that:

- anything that feels "clever" probably isn't. abstractFactoryFactoryFacade
- if you can't describe the code without using an acronym - it's probably something you don't need. ESB/ebXML/UDDI/EJB/Portal blah blah
- a bad solution that's used universally in an application is better then 3 good solutions.

Re: Are You Proud of Your Code?

[sick_soul]

> I am downright embarrassed by the quality of my code.

Good. You recognize you have a problem, thus you are already
getting better.

> It is buggy, slow, fragile, and a nightmare to maintain.

Instead, put your effort into maintainable, correct, and fast-
enough code, in this order of priority.

> Do you feel the same way?

Only in part. As I get better, I see the problems with my old
behavior, and I try to correct it.

> If so, then what is holding you back from realizing your
> full potential?

I do not think there is a full potential, I think there is
always some room for improvement, with diminishing returns
probably.

> More importantly, what if anything are you planning to do
> about it?

I try to always improve myself. Always try to produce the best
I can possibly do, compatibly with deadlines and such.
In no way I allow myself shortcuts for short term gain, which
I could then regret later when I have to maintain the thing.

> [...]
> Sadly the one constant in my career is that I am assigned
> to projects that drift, seemingly aimlessly, from inception
> to a point where the client runs out of funding.

Try to implement those project well. Maybe they'll fail anyway
(management mistakes), but you can find your satisfaction in
that you have done a good job. Probably nobody cares, but you
should. It is what makes coding interesting to me: caring
about the codebase, and improving it (and thus myself).

> Have any developers here successfully lobbied their company
> to stop or cut back on 'cowboy coding' and adopt best
> practices? Has anyone convinced their superiors that the
> customer isn't always right and saying no once in awhile is
> the best course of action?

Yes. "Best practices" is a very relative(!)term, but I get
what you mean. I try to convince the people around me
(especially above me) to avoid half-baked solutions in favor
of good maintainable ones, or at least to avoid panic and
think things through before acting. It is not always possible
to avoid customer-driven development completely, but you can
always make your case, especially if you do not fear to work
more to implement the good stuff.

The key to good code quality is quality estimates

[Anonymous Coward]

(man one of these days I've got to attempt another password recovery lol)

I'm part of the Enterprise Architecture group at the company I work for. As such, not only is good coding skills important to me, it's part of my job to evangelize them throughout our organization. It's actually not too hard to avoid sloppy coding (and, incidentally, the other common problem you mention; running out of money)... the most important thing in my mind is to provide the client an estimate, and to get the estimate directly from the person(s) who will be doing the work. And don't consider code quality or rigorous testing to be an afterthought of that estimate; these tasks are first class citizens of your estimate, just like designing the application or coding the web pages... if you plan for and estimate them from the start, it's much easier to make sure it's accounted for...

Seriously, refuse to work on an application that you aren't given an opportunity to estimate. An estimate is only as good as the accountability of the person making it, and it is both illogical and counterproductive to expect someone to deliver someone else's estimate. I certainly don't quit my job when in a situation like that, but I do make sure I communicate clearly the risks involved in not re-estimating at that point in time... Then when we run out of hours and crucial tasks are left undone, at least it's not a surprise to the client and/or project managers, and they can deal with it appropriately...

I just took a look at my code from 8 years ago

[melted]

...when I was just starting out professionally, and I must say it looks pretty darn good. The key to not be embarrassed about your code is to not cut corners when writing it. If you know you're writing crap, stop and think how to make it better. Don't write crap against a deadline, writing good code doesn't take that much longer. Don't be afraid to refactor/rewrite, just do it during your development/testing cycle, not right before shipping.

It depends

[Nicolay77]

I have to repositories of code 100% written by me.

One of these is for a future closed source software. The code there is beautiful and elegant.

The other one is for a Lisp interpreter. Some parts of the code are elegant, some are pragmatical and the numeric tower stuff is damn ugly.

I believe that it depends on the task at hand. The lisp interpreter is far more complex than the closed source software, and it can't be made 100% elegant, some compromises had to be done.

Last rights

[Tetsujin]

Its like a right of passage or something. Well, everybody should have their right to life, liberty and passage...

code can be perfect

[nachumk]

i like perfection. i use code to get as close to a perfect understanding of the underlying system as possible. the flip side is that once i understand the underlying system i try to insert my code in the system in as perfect a way as possible. of course i am a rewrite fanatic. code is almost never as good as i want it. usually it improves after a few readings, but it rarely reaches the level that i require. reorganizing and rewriting are two of the most hated words for most engineers and managers. i consider these two skills to be my biggest asset. I have no fear throwing out the old, and writing it a new, and it is always better after i'm done. intense thought goes into every rewrite i do, sometimes days of walking aimlessly trying to figure out how to perform these operations in a "perfect" sort of way. I don't like workarounds, and i don't like patches. if something can be done, then it can be done well.

i have many years of experience working for the same embedded systems company, and i have earned company wide respect for my ability to solve anything. my habit for rewriting is known, and was originally "feared" but not anymore. when i want to rewrite something my company is behind me 100%. if it could be done badly then it can surely be done well.

ps. everything has its exceptions but what's written here is the rule.

nachum kanovsky

No, just no

[MortenMW]

Not that long ago I had to write a PHP-script to take care of a couple of pretty simple and mundane help-desk things. I started out with about 4 or 5 different PHP-files, most of them libraries. Then after working on the project for a while, I had something like 30 files, again most where libraries. So I decided to put these different libraries into a single class in a single file. But still I had some seperate files. So, long story short, I ended up with 20 files all depending on at least 2 other files. Whenever I changed something in file A, I had to change file B. If I change file B, I have to change file C. But if I change file C, I have to change file A. I'm sure that if I posted that code here, some of you would probably start feeling sick and end up throwing up before you are finished reading the code. This is the worst piece of code I have ever written. But it works good enough, at least until I have to change something.

Tabbing Spacers!!!

[EgoWumpus]

I prefer two spaces as well; inevitably people set their tabs to different widths, which means they use different numbers of tabs to line things up to make code look 'clean'. When it gets to your machine/IDE it generally looks garbled because *your* tabs are, of course, different. But, worse than that, when you're using tabs you might throw in a space or two to line things up - and then things really become difficult to read. Better to keep it all as spaces, in my opinion. Tabs are for things like theses, where print formatting should be taking up more of your time. But, then, I'm very clearly a visually oriented thinker, so the garbled text thing really irks me.

Re:The normal response of an inexperienced program

[Anonymous Coward]

I'd better not comment on any code then, lest someone thing I'm experienced.

You need some pair programming

[scorp1us]

You need to do some pair programming. Yes, I hated it at first and I thought it was silly. But after a short time, and having generated high quality code, I realized that there is some value to XP. I still prefer to NOT do it, but by not doing it you are depriving yourself of learning from someone else's thought processes. With one person as the coder, and the other playing the devil's advocate you can learn about what you fail to consider. With enough time, you can ask yourself: "what would my partner comment on?" Being able to do that will undoubtedly help your code.

It is easy to get offended when people make comments at first, until you switch places and you realize everyone gets comments on their code. Eventually you should be proud of the code that was done together because it will be better than the other parts of the program. Once that happens, then you should see pair programming as a means to an end.

What's holding him back?

[fahrbot-bot]

"I am downright embarrassed by the quality of my code. It is buggy, slow, fragile, and a nightmare to maintain. ... what is holding you back from realizing your full potential?

OK, what's holding you back?

I enjoy programming and have from a young age (cut my teeth on BASIC on an Apple IIe).

Oh. Never mind.

Lots-O-Comments

[javamann]

I am one of those programmers that put a great deal of comments in my code. On average about 50% of my code is comments (including Javadocs). I have found that pretty much without exception those who complain about the amount of comments in my code don't put any comments in their code.

my code and my wife's but

[sal]

I have the same relation to my code as my wife has to her but. No matter how many compliments she gets, she still can't admit its any good. Sure, it could always be a little better. And the userbase will gripe a bit from time to time when comparing to the newest out there. But the stake holders makers are happy enough not to want to make major changes.

You know,,,

[gillbates]

If you design it right in the first place, you don't have to worry so much about scope creep.

If you design it right in the first place, you limit the kinds of problems you can have; hence, you don't need to spend as much time in testing and debugging.

If you design it right in the first place, you might actually be retained to maintain your code, as opposed to being fired when the whole project tanks. And yes, I have worked at places where this happened.

Design isn't done because management wants to fulfill some programmer's odd views about how things should be done; it's done because management realizes that it reduces the cost of software over the entire lifecycle.

But I wouldn't be surprised if you're one of those types that management loves, but programmers hate. You know, the type who gets things done quickly, but in a manner so sloppy that the code maintainers curse you under their breath.

Re:You know,,,

[Foolicious]

But I wouldn't be surprised if you're one of those types that management loves, but programmers hate. You know, the type who gets things done quickly, but in a manner so sloppy that the code maintainers curse you under their breath. No - I'm the type that lives in reality, even if that reality is annoying enough to drive someone to cast aspersions based on a simple comment. I don't disagree with anything you've said, but you're forgetting that managers make decisions, not programmers. Programmers help managers make decisions, but ultimately managers do what they want. If you've got quality managers doing and promoting all the things you've indicated, then yes, I would be the type you've labeled me as. But just as there are sloppy and poor programmers, there are sloppy and poor managers. Certainly you've got to recognize this.

Coding is not the Big Issue

[Mutatis Mutandis]

I suspect that if you are involved in "projects that drift", then the basic problem is not coding quality. I have recent got involved in some absolutely terrible projects myself, and my impression is that the #1 problem is giving too little priority to design. Software engineers should understand the problem they have to solve as well as the customer -- actually, they should understand it better than the customer. Or alternatively the customer, and not some external IT guy who has first to be taught the basics, should be able to do the top-level software design. (Because understanding the task the software should accomplish, is usually more important than knowing the technical details of the implementation.)

Unfortunately, customers usually assume that software design is a trivial problem that any typist should be able to do after a few hours of explanation. And as for so-called IT professionals --- don't get me started on the crass amateurism that I have witnessed. The result is often that the programmers create gordian knots in an attempt to make the best of a chaotic design. That's not their fault. You'll go mad if you start worrying about it.

But if you have a good design, then achieving good coding quality should not be that difficult, if you are technically competent. I've noticed myself that when I am writing bad code, overcomplicated, unstructured, intertwined, and full of bugs, then the reason is often that I don't properly understand what I am trying to do. Because the design is wrong. If the design is correct, then it should be clear what a piece of code should do, and writing it should be relatively straightforward, and you should not introduce complicated bugs -- because you know how it is supposed to work.

So my first advice is: If you have the feeling that you should to be ashamed of the code you are producing, then stop right there. Probably your design stinks and you don't understand what you are doing. Re-analyze the problem, break it down in components again, make sure that you properly understand every step. Think it over thoroughly. If possible, go for a walk; that usually helps more than staring at your screen. Then first redesign, then rewrite.

As for coding style, I think it is most important to be consistent. I once got back a mathematics paper back from my teacher with a bad grade, not because the answer was wrong, but because there was no method to it. "Use a method" was what he wrote on it. I still hate to admit it, but he was right.

Most people don't use the full vocabulary of their programming tools, which in case of languages such as C++ is not a particularly good idea anyway. Instead they develop patterns which they understand and routinely re-use. It is best to adopt some set of patterns as your own; which one does not matter that much as long as you are aware that you rely on them, that you understand how they work, and are familiar with their pros and cons. From time to time step back to analyze your code for repetitive patterns; and think of what you should do with them -- retain them, build on them, forget about them.

The one advice I would give is that if you are using a coding style that aims for saving on the number of letters and braces you type, that is probably not a good idea. Saving on typing should be at the very bottom of your list of priorities. You should nearly always go for highlighting the structure, if you can.

Personally I also tend to over-comment, documenting every private field and method. And I write my comments first, and the code later, on the principle that you shouldn't be writing a class or a method if you can't explain what it is supposed to do. Of course I usually have to update the comments later, because one always modifies the flow a bit to optimize it, but that is fine.

Re:The normal response of an inexperienced program

[0xABADC0DA]

All programmers criticize the code they inherit. The key point is what the criticisms are. As a rule of thumb:

* Low-level form and factor: The code is written by somebody of much lower ability, so the code is disorganized with lots of run-on functions. You can understand the code, but modifying or maintaining it is next to impossible just as speaking with invalid grammar is very difficult if you know better (ie "somebody sent up us the bomb", or repeating verbatim pretty much anything GWB says).
* Syntax and naming: The code is roughly at your same level of ability. You can understand it and modify it, but you don't want to because it smells bad.
* High-level structures: The code is written by a more skilled programmer. You probably do not understand why the code was written as it was even with documentation, and even if you do then changes you make will cause a lot of side-effects and unexpected errors. Sadly you should rewrite this code because you cannot make other than superficial changes since you fundamentally do not understand it.

Generally the code is at the lowest level you are complaining about.

Another common trait is to deny one's own faults. First of all, if somebody says something is "equally likely" as something else that's almost always some kind of rationalization. There are precious few things that are equally likely (or fair and balanced), and in this case any decent programmer should be able to determine immediately if there are some few ugly sections vs the whole program being a huge pile of crap.

Of course the BIG mistake is to only have one programmer. What happens when they take a break or leave? Everything stops. Another mistake is to have programmers of very different talent (as opposed to experience) working together. This invariably causes the very talented ones to leave and the poor ones are left with code they don't understand.

because management likes it that way

[jay2003]

Most employees are remarkable at aligning their effort with the incentives in their environment. The problem for management is that the employees align themselves with the actual incentives not empty platitudes about how quality is important.

In the software development environments I've worked in management values schedule predictability and turning around projects fast. Management does not care about or even evaluate code quality or long run productivity. They would rather have a short development phase and blow huge amounts of time and effort in maintenance. Lower levels of management might know that sloppy coding has long run consequence but they are incentivized to get releases out quickl. Upper management rarely if ever has any understanding of software development even in companies that exclusively develop software so they don't know any better.

Over time, a project that started with 5 people now has 3-4x times as many people who can't seem get anything done. Changing anything seems to result a cascade of bugs.

The solution would be measure productivity over the life of system but in most environments are way too short term focused for that.

C++

[huckamania]

When I deal with c++, and it's not often as I do mostly system level stuff, I'm usually looking for 'the work'. That is, I know that 'the work' is being done, but finding where that code actually is turns into a nightmare of following inheritence trees or container classes or vtables. Once I find 'the work', changing its behavior is usually pretty easy.

The funny thing is that I transferred from one University to another for the sole reason that the first wasn't teaching any c++ classes (though they still required pascal). Now I look at c++ as being 'too much rope' for the average programmer.

C++ was supposed to make things like reuse easier. It doesn't. C++ was also supposed to make code cleaner and easier to understand. It doesn't. Sure, you can write clean, reusable code in C++, unfortunately, it's not the usual outcome.

Who cares?

[Anonymous Coward]

As long as your code works, who cares? Okay, forget efficiency and all that, when you have 1 week to work on a program someone wants, there's no time to tidy your code up unless you're nearly finished with it.

In 2 letters...

[worldcitizen]

>I am downright embarrassed by the quality of my code. It is buggy, slow, fragile, and a nightmare to maintain. Do you feel the same way?

No.

Honestly, most of the time writing bad code is not faster than writing reasonably good code.

To improve even more, try having a policy of doing a quick code review before non trivial check-ins. Knowing that you'll have to show and explain your code to a peer, that does help in resisting the temptation to take some shortcuts (e.g., why save time writing when it will take longer to explain). Code reviews should be easy to "sell" to upper managers, as they provide a certain degree of mitigation for the risk of one programmer leaving.

Best practices = bad code

[sigmabody]

Personally, the worst code I've had to write has been when I had to follow so-called "best practices". Things like excessive comments which quickly become out of date and incorrect, dictated program structure which doesn't correlate with the intent of the code, etc. Also, the more rules/procedures the company has, the slower people code, the less creative they try to be, and the more they resign themselves to just putting in their 8 hours a day following the rules, instead of trying to produce as best they can and get better at their profession.

Sure, there are ways to write good code. However, I find that whenever manager types get involved with dictating the rules for coding, you end up with worse code. That's my experience, anyway.

my answers to your questions.

[Interested Spectator]

Do you feel the same way? Not anymore. I did and do about code I wrote when I first started. But I like my code now. If so, then what is holding you back from realizing your full potential? I learned design patterns and how to implement them. That's what's made me a better programmer. Have any developers here successfully lobbied their company to stop or cut back on 'cowboy coding' and adopt best practices? No because most non-programmers don't agree with the business value in it. But, implementing design patterns to solve my problems helps enormously. Has anyone convinced their superiors that the customer isn't always right and saying no once in awhile is the best course of action? No. Cuz the person with the money is always right, or they'll pay someone else to do it.

Documentation, Commenting,...

[Univac_1004]

..and "Design Patterns" by Gamma et als. 'nuf said.

Work is for Crap; your Free project is for Quality

[mkcmkc]

After many years of making myself miserable thinking like this, I've realized that--at least in software--money and quality just don't go together. My advice:

• Try to do as good as you can at work, knowing in advance that the results will be fully compromised. The purpose of this work is to make money so that you can support your family--that's it.
• Do outside work on at least one Free Software (or OSS) project that meets your standards for quality. This is where you get your professional satisfaction.

Good luck. Mike

Computer Science degree, before and after

[fatalGlory]

My code before I started taking computer science was largely modelled on the coding styles of whichever projects I'd been recently reading the documentation for (I used to spend a lot of time going over the GTK+ api docs for example). Now, after doing Comp Sci for a year, I'm starting to develop my own style (by taking the techniques I'm taught and modifying the ones I dislike), which I'm quite proud of and I think works rather well. My code is modular (broken into functional, replaceable sections) and hence easy to modify, easy to debug and easy to document. I say easy to document because their can be "high-level" documentation that describes what each of these modular pieces actually does (for a forest-for-th-trees kind of overview) and then, their is low level documentation describing how each modular piece does its job. By breaking it up into sections (big task? put it in a function, even if you only use it twice), the documentation job is much less daunting. A practice I highly recommend. As for judging other peoples code, I'm probably pickier about my C/C++ but I remember starting javascript at age 13 and seeing someone use a for-loop to go through all the elements in an array using the array length as the loop counter and the index of the element inside the code block and thinking "Wow, that is really clever, its concise and when you know what it does it makes heaps of sense." I think we're most impressed by coding technique we feel we would never have thought of.

Mental Compiler?

[TheVelvetFlamebait]

Wow! Just wow! I mean, I can do a mental interpreter, but you're saying you can actually compile your code mentally? You must have done decades of mental training!

Have you considered changing your profession from programmer to jedi? You could probably give Yoda a run for his money.

Re:Mental Compiler?

[Tablizer]

Have you considered changing your profession from programmer to jedi? You could probably give Yoda a run for his money.

I bet Yoda uses Reverse Polish Notation.

That's Not Good Code

[severoon]

The biggest thing I see wrong with other people's code is not at the syntax level or to do with commenting. It's based on a misunderstanding of basic CS principles. An example is in order from last week...

In the codebase I work on, there's a module that analyzes documents and tags them, assigning different weights to each tag based on relevance. (Think of the way google works--it reads a web page and tags it with terms, then if you type in one of those terms while doing a search that document comes up--yes I know this isn't the way google actually works, save it. :-p ) At one point we send a list of tagged documents from one system to another, and this area was the source of many, many bugs. The responsible developer spent the better part of last week slaving on this code and every change seemed to introduce more bugs than it removed. Finally, I got involved to see what the problem was.

Here is one thing (out of many) that I found. After the docs arrive in the new system, each doc is supposed to be persisted along with the top 5 most relevant tags (the rest discarded). The code was written to create a Document, check a hash table that maps the doc to the number of tags it currently has, add a tag if that doc doesn't yet have five, then increment the value associated with that doc in the hash table. When I saw this, my head almost exploded. At some point, this developer thought it would be a good idea to create a hash table and keep this information, information which is available in the document itself (he could've just called doc.getTags().size() to see how many tags it currently had). Now he created this hash table and all his code was written to depend on it, so of course he had to write a lot of code to keep it in sync with the state of all these documents.

This sounds like a simple enough thing, right? It's not necessary, and it's not the best thing, but it's a fairly simple mistake and one that couldn't impact code readability all that much, right? Maybe--but consider that this is one of about 10 simple mistakes I found, and you can imagine the explosion of interactions of all these simple mistakes...and that's why we burned a person-week on something that should've been trivial. When I pointed out to this developer that he could just get the number of tags directly from the doc itself, and doesn't need to keep this state in some other object too, he said something to the effect of, "That's a different approach, but whatever...one's not better than the other."

But one is better. If this developer understood the difference between intrinsic and extrinsic, he never would've written that code in the first place much less defended it. To put a fine point on it: the number of tags associated with a document is intrinsic to the document itself, so that is where the information should live...not there as well as some hash table somewhere. The document is the authority and the final word on how many tags it has at any moment in time. (There's a principle in databases called the SUA Principle--it means one should keep data in a Single place, in an Unambiguous manner, and that should be the Authoritative source of that data and no other. It applies here too.) Putting this info into some other object, even if that object exists solely for the purpose of tracking that info, means you're creating an object that stores information that is extrinsic to it. Never a good idea...now you need a whole bunch of supporting code that keeps the extrinsic info in sync at all times.

Let's say I'm designing a Ball class for use in a physics application that students learning physics can use. They can shoot the ball out of a cannon, put it under water, in deep space, on Jupiter, etc, and see how the simulation behaves. As the developer of this class, I decide to add a characteristic to the ball that keeps info about its "heaviness". What should I add, a getWeight() method or a getMass() method? The developer I was talking t

Re:That's Not Good Code

[SilentBob0727]

I'm not even sure what that value would be if the ball were under water and buoyant. Since weight is the net gravitational force acting on it, same as if it were suspended in air or sitting on a table at the same elevation.

I would actually consider writing a superclass or mixin called MassiveObject that knows how to calculate mass-based forces between it and other MassiveObjects. Separation of concern, you know.

Re:That's Not Good Code

[severoon]

When you define an API, it should always be in service to what clients may want. So, if the physics app you are trying to write would be concerned with the gravitational aspects of a relatively tiny ball, then I agree, by all means add your method. On the other hand, if clients would never be interested in calculating the gravitational force of two balls out in deep space (or some similar application), then adding such a method unnecessarily complicates things.

One thing to keep in mind is that OO code is not math or physics. Consider the following classic example: I'm writing a geometry library and I have a Shape interface. I implement that interface with Rectangle, Circle, Triangle, etc. Then I get to Square. Should Square extend Rectangle? After all, a square is a kind of rectangle, as every schoolboy knows...right?

Except in this case, it's not. A square may be a type of rectangle in geometry, but in an OO system it would be improper to represent a square as a subclass of rectangle because behaviorally speaking a square and a rectangle are different, and OO regards classes as behavioral objects, whereas geometry regards shapes as characteristic objects. In other words, in geometry, if you have 4 sides and 4 90 degree angles (in Euclidean space) you're a rectangle. A square has those things, so it's a rectangle. In OO, since a rectangle and a square behave differently with respect to pretty much every sensible API you could assign to each, Square is not a subtype of Rectangle.

Of course, that's a great example because it's pretty much true across the board. Very few examples are true in that way—in nearly all cases, f you're arguing with a colleague about whether this should extend that or aggregate this other thing, context matters. I've often discussed possible designs with colleagues where they correctly argue that, for some particular application, their approach is correct. What I always try to get them to focus on (if we have a disagreement) is forget about some general, archetypal application. In our application, in this context, does it make sense?

Example: should Automobile aggregate Engine or should Automobile associate an Engine? (The difference is: aggregation implies a "part-of" relationship in which the containing object partially derives its identity from the contained object, implying the two have similar lifetimes. For instance, a building aggregates a room because it doesn't make sense to have a building with no rooms or a room without a building, when you new up a building the constructor ought to new up one or more rooms, they're born together and they die together. A surgeon and a scalpel, however, are a different story. A surgeon may never use a scalpel for a particular surgery because only other tools are called for, so that would merely be an association...a surgeon is still a surgeon, scalpel or no, but what would you call a building with no rooms?) In this case, it's impossible to say whether Automobile should associate or aggregate an Engine. If the clients of the Automobile API are owners that will only be interested in driving it, then it should probably aggregate Engine. If the client using the Automobile API is an auto manufacturing plant, then perhaps it makes sense to merely associate the two.

This is the problem with your answer above. It takes no account of the actual application the end user has in mind for the Ball class...you simply state that you would do it X way. If clients desire that behavior, great...but if none of the use cases would ever need that kind of functionality, you might be adding complexity with no pay-off.

Re:That's Not Good Code

[DusterBar]

I am very confused as to your Square and Rectangle example... Why in the world would Square not be a subclass of Rectangle?

The only thing about square that is unique to it over rectangle is the constraint that width == height. That type of constraint is exactly what subclassing is good at controlling.

All of the other attributes and methods are the same: calculate area, draw outline, draw filled item, rotate in 2D, draw in 2.5D perspective, map to a 3D surface, scale, etc.

So why in the world would Square not be a subclass of Rectangle? (Or just an attribute of a Rectangle?)

In fact, the Square would *be* a Rectangle - thus it would be polymorphic with Rectangle as both expected and as per behaviors. Not having it be a subclass is almost specifically wrong, both in code reuse and in behavior.

Re:That's Not Good Code

[Anonymous Coward]

A square is-a immutable rectangle, but no more. If Rectangle includes independent setHeight and setWidth methods, a Square instance is not Liskov-substitutable because it fails to support the whole design contract. It has no business being called a subtype if some methods don't work and never will; it's an abomination which should be put out of its misery.

For this reason some languages distinguish a subtype (common interface presented to clients) from a subclass (implementation happens to be shared), though the latter is really just a special case of delegation.

Besides, in some ways a square is more similar to another regular polygon or to a rhombus than to an arbitrary rectangle.

Re:That's Not Good Code

[severoon]

"A square is-a immutable rectangle..." Your point is well-taken, and this addition of immutability goes a long way to aligning OO with mathematics. Even this is not universally true, though it is obviously true in almost all cases. Theoretically, I can think of an application in which it would not be appropriate to make an immutable square extend an immutable rectangle.

Say I'm writing an application that applies mathematical transforms to 2D geometrical objects and creates a new object based on the result. Let us further presume that all such transforms must be defined such that they are operations that exhibit mathematical closure. In other words, if the transform operates on circles, the result of such operations must also be circles.

I define a transform that operates on immutable rectangles as arguments. Specifically, it is a unary operation that takes a rectangle and produces a result that is 2x in width and the same in height. If I pass in an immutable rectangle with dimensions [4,1] I get back a new rectangle with dimensions [8,1]. In this scenario, for closure to hold, both the input and the output must be from the same set (rectangles). If I now mistakenly let square extend rectangle, this transform is no longer meeting the requirement that it demonstrate closure. The compiler will allow me to pass a square to this method as a rectangle argument, but instead of producing a result from the set of squares, it will most certainly produce something from the set of rectangles as a result. If I'm creating this new type square as I did rectangle—in order to treat it as a new kind of set on which a set of transforms can operate with closure—then allowing it to extend rectangle is most definitely a mistake.

I wish to avoid a detailed discussion of the subtleties of this particular example (as I believe that I would quickly find myself out of my depth) and trust that my point has landed...which is: we can say that a square should not extend rectangle, and regardless of the application under consideration, it is universally true that such a design allows us to respect all OO principles. On the other hand, it is only true for a subset of these applications that we can respect OO principles if square does extend rectangle (square and rectangle must be immutable in certain ways, etc).

Re:That's Not Good Code

[severoon]

Though I'm sure you can design a particular application in which a square is behaviorally a rectangle, and therefore it would be ok to have square extend rectangle, it is not universally the case.

One of the best things I ever did was head over to Object Mentor's published articles page and click on the Design Principles category. There you will find a paper on the Liskov Substitution Principle which defines exactly when it is appropriate for one class to extend another. (You won't go wrong reading all the papers in that Design Principles category—I found them riveting for hours on end.)

In this particular case, behaviorally speaking a rectangle has two degrees of configuration freedom whereas a square has one. So, if you think about the actual practice of defining a Rectangle API with get/setWidth() and get/setHeight() methods, you could then write a unit test against those methods to fix the proper behavior of a rectangle. One of those unit tests might go something like: {1} set width to 1, (2) set height to 2, (3) assert that getArea() returns 2. I challenge you to now implement the subclass of rectangle called square that will pass this unit test which behaviorally (and correctly) verifies rectangle-type behavior.

Your suggestion of making squareness an attribute of rectangle is interesting and one I have not yet heard in any of the instances I've presented this example. I imagine it would take the form of something like the method boolean Rectangle.isSquare(), and would return getHeight()==getWidth(). This would work, as long as clients to the rectangle API understood that its square-ness is temporally defined and could change in the next moment. This is, however, an important consideration, though. In making this a requirement of what it means to be a square, nearly all definition of the square is itself lost...the concept of a square becomes a temporal thing itself. The old mathematical standby of an object that forever and always has equal sides is no longer relevant to this implementation.

Re:That's Not Good Code

[Anonymous Coward]

Interesting thought experiment. It's pretty similar to non-Euclidean geometry, in which perfect forms like regular polygons become irregular or asymmetric if merely moved. isRegular starts to look more like a predicate than a type.

My humble advice

[orangehead911]

In my experience, the following principles seem to consistently produce good outcomes for both devs and customers alike:

• Use all or some aspects of Agile development methodologies. One of the pillars is that the customer is involved in the planning process, and can thus immediately see the affect on the progress of the project, and the deliverables, when he changes his mind.
• Use Design Patterns and generally accepted Good Design Principles.

The first point mainly addresses issues at the project/team level. You can find more information on Agile at http://www.objectmentor.com/resources/articles/Agile_Methods_-_The_Bottom_Line.pdf

My second points bears directly to the issue of code. There are many ways of solving problems. One is to bulldoze ahead and use ad hoc programming, dealing with bugs and design issues cropping up everywhere as you go along. Another one is to leverage other people's experience in the forms of design patterns and good design principles.

I used to use OOA/D and ad hoc programming. Code would work, but defect repair and adding new features would most of the time take a huge effort. I now realize that good OOA/D skills alone isn't enough. Without the aid of design patterns and good design principles, I would be much worse off (no, there's no kool-aid involved.)

The Object Mentor website ( http://www.objectmentor.com/resources/publishedArticles.html ) is a great resource. The Wikipedia project has a lot of pretty good programming related topics ( http://en.wikipedia.org/wiki/Design_pattern_(computer_science) ). Good luck!

Indentation and meaningful variable names

[powermacx]

Consistent indentation and meaningful constant/variable names are the two main things I appreciate in other people's code.
Finding code that looks like this is far more annoying than the lack or excess of comments:

if (krh == 3516) {
    if (tr3 == 'g') check(tt);
else
    return false;
}

Now imagine misleading bits like that all over the code.

Piece of cake!

[slashbart]

Hi
No problem. About half of all the code I've written in my 20 year career is for use in spacecraft, or space related stuff on the ground. I have absolutely zero problems convincing management that code quality is paramount. Coding is only a small part of the product development time anyway, documentation (Requirements, Architectural Design Document, Detailed DD, Test & Verification plans, lifecycle plan,...) and test activities take ca. 70% of total time.

I've coded in assembly for Mir, in C for Spacelab and I.S.S It doesn't get much better :-) So my advice: try to find the right place. Embedded programming typically has to be better quality than for instance web apps. People just don't tolerate a washing machine that needs a three finger salute (or a spacecraft for that matter).

Life is good.

You have to code defensively...

[Kazoo the Clown]

You need to get into the habit of planning for the unforseen. I think a lot of that comes with experience, after a few hard knocks with projects where new requirements caused a lot of ugly hacks to go in because the original code wasn't flexible. Every time I write a function I try to think of how else it might get used or abused and try not to lock out such growth. Often for me, it's a matter of realizing that there are features they are going to want that they powers-that-be haven't thought of yet, and coding for the eventuality. It won't completely eliminate the problem of "drift" but it can help...

Here's the cause of your problem

[Jim the Bad]

...someone with adequate skills and all the knowhow that was required besides the actual programming. As we were on a tight budget, it was important for us to find that one guy who didn't expect a zillion dollar salary.

Eg, you wanted a professional but didn't want to pay for it. The result was fairly predictable from that point on.

Modular?

[Nicolay77]

Sometimes you can't make them modular.

You put all the headers inside #DEFINE statements in each .h file.

That way you can include them ten times and only the first one is processed.

Make yourself proud!

[sinnema313]

Have any developers here successfully lobbied their company to stop or cut back on 'cowboy coding' and adopt best practices?

You don't need to lobby for best practices. How could anyone be against that? Just do it. Make no noise about it, don't expect awards or anything, just go about it.

As always, start small. Introduce best practices one by one. And don't go overboard. Unit tests are good, but you shouldn't spend the next three months doing nothing but writing tests. After all, you get paid to provide business value.

And remember that sometimes little things can have big impacts. Static code analyzers can sometimes find bugs for you without you even having to write a unit test. A unit test that catches a bug introduced by a co-worker may get his interest in unit testing. And if the little things you do have only little impact, well, that's fine too. After all, you're in for the long run, aren't you? You're running a marathon, not a sprint.

Has anyone convinced their superiors that the customer isn't always right and saying no once in awhile is the best course of action?

Yes, and no. Mostly the customers are right. After all, they are the ones using the software, not you. But I work on shrink wrapped software and sometimes what one customer wants is just not what most other customers would want. In those cases, you need the luck that the one calling the shots notices this too and isn't blinded by $. In the former case, you're blessed. In the latter, well, you probably have more than one problem...

TABs are good in C. Spaces are good in Lisp.

[Nicolay77]

If you code in a language with C syntax TABs are better.

Some people prefer 4 spaces for indentation, some 2 and some 8. Tabs lets all of them work in the same file with ease.

Spaces should be used in languages like Lisp. In fact, all your arguments against TABs were first done by Lisp programmers, and were done against TABs in Lisp source files.

I don't know how the hell can you format C code to need spaces mixed with TABs in front of the source lines. (Something trivial in Lisp, as every single character indentation counts there.)

Re:TABs are good in C. Spaces are good in Lisp.

[Abcd1234]

If you code in a language with C syntax TABs are better.

Says you. My experience is the opposite. All tabs do is give the editor an opportunity to a) fuck up the formatting, or b) mix tabs and spaces.

Besides, imagine you have code like this:

call_my_function(a_really_long_argument,
                              another_long_argument);

Where the arguments are meant to line up (thanks a lot, Slashdot, for having no preformatted option).

In that case, tabs will screw things up because, unless that paren happens to line up exactly on a tab boundary, you're gonna have to mix tabs and spaces, and then variable tab widths will screw up the display. And before you ask, no, I *hate* this:

call_my_function(a_really_long_argument,
        another_long_argument);

ie, having the second (and remaining) arguments indented one level deeper. It's ugly. The former visually groups the arguments. The latter is a hack so twits who use tabs won't have a screwed up display. :)

Re:TABs are good in C. Spaces are good in Lisp.

[Abcd1234]

BTW, the above example also applies to complex if() statements, and anything else where you have parenthesized lists.

Re:TABs are good in C. Spaces are good in Lisp.

[Anonymous Coward]

If you code in a language with C syntax TABs are better.

No, you like tabs better than spaces, but neither one is inherently better than the other. There are arguments for and against both.

I personally prefer spaces since they allow me to write my code in a way that I'm sure will be readable to others. I can't do that with tabs if someone picks an extreme tab size (like 8 from your example). When writing code, there will be long lines that need to be wrapped. Choosing when to wrap lines is highly dependent on how much screen real estate you have to work with. Only spaces will give a constant for this value.

From my experience, if you just make everyone get used to 4 space indentation with verbal beatings for everyone who checks in a file with tabs makes everyone's life easier. People not used to that indentation get used to it pretty quickly. And once you get to that point, there's no more problems. Contrast that with the situation where tabs get used and you will constantly be running into issues where code is harder to read because line wrapping decisions were made by someone who's tab setting is different than your own.

But, as I said, there are arguments to be made on both sides of the issue. Tabs vs. Spaces is a holy war that will give Emacs/Vi a run for its money. The only thing that everyone pretty much agrees upon is that mixing tabs and spaces is the worst of the three options.

Re:TABs are good in C. Spaces are good in Lisp.

[Nicolay77]

I see your point. In that case the solution is to use spaces after the column where the call_my_function starts, and TABs before it:

TABS: #
SPACES: .

# # call_my_function(a_really_long_argument,
# # ................another_long_argument);

Still better to use TABs if you share your C code with people with different TAB preferences, like me.

My editor doesn't automatically replace 4 (or 2 or 8) spaces with TABs unless I tell it to do so.

If your editor does it, you will suffer and curse and hate TABs.

Re:TABs are good in C. Spaces are good in Lisp.

[Anonymous Coward]

That arg list is a big block-like thing, so it should look like one.

call_my_function(
    a_really_long_argument,
    another_long_argument
);

I'd no more cram the first arg after the open paren than I'd cram the first of several statements after the open brace of a loop. It also leaves as much room as possible for unreasonably large expressions and comments.

Re:TABs are good in C. Spaces are good in Lisp.

[Abcd1234]

Do that with an if statement and tell me it looks readable. Please...

Re:TABs are good in C. Spaces are good in Lisp.

[Anonymous Coward]

I probably wouldn't do that (a funcall that's this much of a pain in the ass might need temporary logging to see what it returned or how long it took), but if I absolutely had to...

if (call_my_function(
        a_really_long_argument,
        another_long_argument
)) {
        first_statement;
}

On the contrary

[DerPflanz]

I am pretty proud of my code. How? I design my program before I start programming. I think before I fix a bug. I test. A lot. And after that, I test again.

Good example I had today. There was a bug in my code that was a bitch to fix on-site (I work as a systems programmer in industrial automation). My boss tells us to never, NEVER program on-site, and there is a reason to that. When I got the code back at the office, made some tests to simulate the results and did some severe thinking, I fixed the bug by changing 2 bytes. Yes, you read it right, two bytes. If a bug is fixed that easily, it means your code design was pretty correct.

Adn this is not an incident. In the same project I had more simple fixes to seemingly complex problems before. For me, a sign of good design and proof that I am FUCKING BRILLIANT ;-).

Mod parent up: comment != reasoned comment

[waterbear]

I agree with the parent post that ... ... this gripe with over-commenting is fundamentally flawed:

IMHO there's a deep fallacy in the flip comment that ...
If the code is written well, it will speak for itself.

Real-world program code is written for at least four 'audiences': the author, the machine, the user, and the maintainer.

The first three of these need only 'worry', in the aggregate and at a minimum, about the code compiling and running ok with correct results.

But the fourth has an additional worry: to know about the design (or at least part of it), and its purpose.

For these audience members, the code must amount -- somehow or other -- to a sufficiently explanatory description. The question is, what is sufficient?

(Clearly it's of no use at all in anything except an exercise for language-learners to comment at the level that int i=0; declares and initializes an integer.)

How much real background you give to explain a story depends, mainly, on what you think your audience already knows.

Code itself can intrinsically give only part of a story -- the concrete operations or conditions that are to be performed or set up. That doesn't in itself tell the maintainer why it is being done. (Sometimes it doesn't even indicate when it is going to be done -- in any way that illustrates the purpose.)

Some coders seem to think, that they should be able to ignore any members of their audience who don't know or understand as much background as they do themselves. They may have reasons of pecking order, or maybe it's a matter of imagined professional honor. Some coders may even think, that if they give out more than a very few snippets of explanation, they may even be letting themselves or their colleagues down, with a risk of giving out some kind of a subtext message, that they believe their audience doesn't know or understand very much. (Such factors as these could also explain the tones of scorn and contempt that sometimes seem to creep into these discussions.)

But it's important to acknowledge frankly that there can be all kinds of reasons why the audience, especially the maintainer, may not be acquainted with the reason for this or that aspect of the code.

(At the moment I'm writing some code that is full of arbitrary-looking numbers and features that come from outside standards. Maybe it's an extreme case. But it's been a non-trivial issue here even to determine on checks for correctness -- let alone actually carry out the checks, and very hard to know where and how to put in any modifications. That's true already for me, let alone anyone else who may come to it later on. So my comments here are for my own benefit as well as for any later-comer. The comments cite external sources and reasons for the commented features, including literature-references and a few words about what they stand for. This is code that can't possibly speak for itself.

But I've seen code with equally-strong dependence on the outside world, 'cleaned up' and 'prettified', by getting put through a formatter that strips out comments, indents 'nicely', and then substitutes all the meaningful variable-names with totally meaningless ones. The result is totally unintelligible and uncheckable -- and valueless.)

So my take on this is -- if in any doubt (and that's practically always), tell the story.

-wb-

Re:Mod parent up: comment != reasoned comment

[Anonymous Coward]

Some coders seem to think, that they should be able to ignore any members of their audience who don't know or understand as much background as they do themselves. They may have reasons of pecking order, or maybe it's a matter of imagined professional honor. Some coders may even think, that if they give out more than a very few snippets of explanation, they may even be letting themselves or their colleagues down, with a risk of giving out some kind of a subtext message, that they believe their audience doesn't know or understand very much. (Such factors as these could also explain the tones of scorn and contempt that sometimes seem to creep into these discussions.)

And some coders are simply assholes.

I once worked with a guy who intentionally made his code confusing. I guess it made him feel like a stallion with the wife when he got home.

We were using S/360 assembler. Aside from the basic branch on [condition code], there were what were called extended mnemonics.

So, after an arithmetic compare, you might want to take a particular branch if one number was more or less than the other. Instead of remembering that this should be, e.g. BC 8, you could write BNE (for Branch if Not Equal).

Instead, he'd use a mnemonic for a different context, as long it still generated a BC 8 -- say a BM (for Branch if Mixed, appropriate after a test under mask operation).

Like I said, some coders are simply assholes.

Wasted Time?

[maz2331]

Uh... no it isn't. I don't give that time away for free, it's billed at a nice hourly rate. The more design time, the better.

Patterns dodn't work

[Tablizer]

Patterns were developed to create a common ground where people can think about problems in a similar way.

I don't think that's worked. If anything, they've just created more confusion and more ways to head down the wrong path. The more experienced developers merely call them "suggestions to consider", not a central bible of truth.

Intelligent Design Programming

[Tablizer]

I had this problem with a guy that was complaining that my code was full of GOTO statements, used all global variables, and didn't have any comments or subroutines.

Goto's are "in". They are part of the Organic-Driven Programming craze. The brain has biological wires all over timbuktoo and back, so why shouldn't your code? Goto's were good enough for God, so they should be good enough for you too, a lessor being. Let the Vine Shine! Blocks and subroutines are for liberal control-freeks.

-1 Troll

What about programming languages?

[musicbear]

Let's don't forget that we also need better programming languages. After all, we think and speak in human language, and code is written for machines to understand. Often, even when you can think of a clear and beautiful solution, converting it to actual code still takes ridiculous amount of time, experience, pain, and frustration; consequently, the results are bad code and poor program structures that are very difficult to maintain and evolve. We need better programming languages that can take high level human descriptions and convert them automatically to machine code. I guess this sounds like a joke, maybe for now, but who knows what we will have in ten to twenty years.

Re:The normal response of an inexperienced program

[Darinbob]

It's very likely the original programmer thought of and tried the way it should be done, then found the flaws in this approach and adopted methods that produced the results.

But that programmer needs to add comments to the code in this case. This is the sort of thing that drives me crazy at times. If I'm changing the code to fix a bug or add a feature, I sometimes feel that I may be retrying solutions that the original author already tried and rejected. I can't tell if the code was the first attempt or the last of a sequence of experiments without some comments or documentation.

Of course the BIG mistake is to only have one programmer. What happens when they take a break or leave? Everything stops.

Cross-training helps, and design reviews. Most places can't afford redundant engineers to put two people on one feature.

When I write my code I try to keep in mind what could happen if I'm in an accident and my coworkers have to maintain the code. I don't write comments for myself necessarily, but for the poor soul who has to deal with the code when I'm not there.

(I had pneumonia in college once and my project partners for one class were in my room every day listening to my hoarse whispers about how my part of the code worked. So I learned this lesson early :-)

Depends on the code.

[Anonymous Coward]

I am very proud when I come up with a compact, easy to understand way of doing something. Especially when that tiny bit of code is easy to harden until it is bullet proof. I am proud when I can take existing code and make it twice as fast or faster. When I can take existing code that is a mess of interlocking hard to understand functions and change it around so that it has clear easy to understand and test interfaces.

Awwww

[PPH]

I am downright embarrassed by the quality of my code. It is buggy, slow, fragile, and a nightmare to maintain.

There, there now Bill. Things can't be that bad.

Re:comments are important

[thejuggler]

I fully agree - Having well worded comments is just as important as well thought out code. There are many times when I am debugging a piece of code and I know what the code is doing by reading the code, but since there are no comments I have no idea what it is supposed to do. And if you have to work on code that is not documented anywhere , except in the murky gray matter of someone that thinks they remember telling someone to write something, the in-code comments become essential.

I typically preface my more complex code blocks/functions etc with a brief algorithm this way someone in the future knows what I was intending to write and well and when I am writing I can verify that my code does what my algorithm says. This sort of documentation also helps clarify the task and helps define all possible logic scenarios. This way you can write a more complete, stable piece and possible bug free (yeah right) of software.

This is just a mature way of programming.

P.S. - I never claim someone else's code sucks just because they don't have my 'style' of coding. I just want the code to work properly.

Customer = Wrong

[7Prime]

The unfortunate truth, and this goes for ever profession, is that the customer is almost NEVER right, in fact, you can count on them being wrong about 95% of the time.

The worst part is when the customer doesn't know what's best FOR THEM. Especially when it's your job to do what's best for them... then you have a contradiction. I work in advertising, and I run into this constantly. It's my job to help my clients sell their products/services, and they've hired me to do just that. But many times, clients think they know how to do it themselves, and then tell me what to do, when their ideas could, likely, harm their image and their sales.

What do I do? They've hired me to do my job and help them, but their very instructions will certainly harm them. My hands are tied, I just want to scream at them, "Let me do my job, and make you lots of money!"

Every several months...

[chubbchubbs]

I look at a piece of code and say: "Who wrote these f**king lame code in our project? It sucks."
And it turns out to be me. Well, I'm just having a second thought on how to do the job.

I used to be..

[spiffmastercow]

But not anymore.. Well, I take that back. I'm proud of some of my code, mainly the libraries and such. But most of my code for work is in C# using ASP.NET, writing random pages for people to get various reports, change database settings, etc. I tried to keep things clean for a while, but I came to realize that:

1.) Users want quick changes to things, and don't want to listen to why it's going to take longer to do it *right*
2.) Most of the stuff I do does not need to be repeated, or if it does its rare enough that its much more convenient to simply copy code than to create 5-6 new classes to do something that's only going to get used on 2 pages
3.) ASP.NET does everything it can to discourage you from creating your own web controls
4.) I just don't care enough about *this* kind of programming to put any more effort into it than I have to

Now the stuff I write for fun.. That's a completely different story.

broken patterns

[sentientbrendan]

I've spent a lot of time improving how I write code, and one of the most frustrating things that I've come up against are that a lot of people present programming techniques as magic bullets, but then when you go to use them, you find that they haven't actually been thought through very well.

Consider the famous patterns book by the gang of four. If you do a lot of software development, you probably know what I'm talking about. This book is referenced more in general software design discussions than any other. People often proscribe solving some software problem with a solution from the GOF book, or various article that present other patterns in a similar fashion. The problem is that some of the GOF patterns and derived patterns are inherently broken! They were written up perhaps because they were widely in use in some communities where certain sets of problems don't have to be dealt with, but if you take them outside of that, they can blow up in your face.

Probably the most obvious issue is the singleton pattern. In its most common implementation, it allows you to grab a universal single instance of an object through a static reference. It is highly convenient and almost universally used. However, it makes it almost impossible to do dependency injection, and breaks the ability to do light weight unit testing on many areas of the program! In practice, singleton is equivalent to and just as bad as a global variable, yet it is proscribed all over the place. I wish they'd revise the book with a "singleton considered harmful wrt software testing" warning.

Another pet peeve of mine is the visitor pattern, or at least how many people use a variant of it in practice to solve the double dispatch problem. This may be a bit esoteric for slashdot, but let it be known that visitor is in no way a good solution to double dispatch. Think about it! Every class in the hierarchy needs to know about every other class in the hierarchy. That is not encapsulation! An addition of a class requires changes to every single other class! It isn't even possible in many situations (if you have a lot of classes, or if you need to load some classes dynamically from a plugin). The visitor pattern is widely proscribed here, but a little thought and experimentation reveals it as a horrible hack! That said, the double dispatch problem doens't have a great solution in C++ and some other languages, but some form of dynamic typing (which is otherwise a bad idea in most statically typed languages like c++) is clearly necessary here.

Anyway, those are a couple of my pet peeves about how software development is practiced and taught. Generally I've found that coming up with flexible, correct, and efficient software is a difficult, but fascinating problem. While there's a lot of people who are domain experts and know how to write a compiler, a web app, a video game, or some other kind of software really well, I don't think I've seen a lot of good general approaches to the problem of software. Everyone seems to think they have general patterns, but this is largely due to the fact that people overly specialize and don't step outside their field enough. In practice, engineering seems to be about finding the simplest structure that solves the local problem (which is fine, great even for practical purposes) and we've yet to address a lot of the general problems of software development.

Re:broken patterns

[Shados]

A quote I use a lot, and that came from me (though its fairly obvious), is that the only person worse than someone who has no clue how to design software and use patterns, is someone who knows a "little".

From the tone of your post, I'm sure you've been in that situation, and you know what I mean :) People who use Factories that are not -quite- factories, people who use Visitor all over (omg...and you mentionned that one), people who talk about Aspect Oriented Programming but have no clue whatsoever what it means... Those are downright dangerous, and drive me totally insane.

People really need to understand that its about the -WHY-, not the -HOW-... the design patterns are documented as being solution to problems, not solutions in search of a problem, and it causes all the issues you mentionned when developers miss that line.

As a sidenote, I've found that simply, any object that accesses a singleton should always do so through a pluggable factory, or a virtual factory method, so that you can decouple it. That solves most problems. And Visitor is definately overrated... in most cases, a much cleaner and simpler solution can be achieved by changing one's design a bit and using a cleverly put Observer pattern. Easier to implement anyway, and decouple things much better.

Depends

[Scud]

When it comes to PC-based code (VB, C++, whatever), I've got a few "Hello World" programs that I'm particularly proud of. Everything else always seems to be a work in progress.

But that's not what I'm paid to do, I write software for PLCs (Programmable Logic Controllers). PLCs are used to control automation (as in the machines in a car plant).

It's pretty much based on the bit level (we can do multiplication and division, but it's mostly a graphical representation of Boolean logic).

We get inputs from the machine (pushbuttons, limit switches, pressure switches, temperature RTDs, etc) and based on what we want to be on, and just as importantly, what we want to be off, we turn on outputs to run motors, light pilot lights, whatever. Now that code I'm proud of.

Are You Proud of Your Code?

[__aahgmr7717]

Use a good language! That will reduce the complexity of your code greatly. Forget C/C++. You just can't write good code in those languages. I prefer BlackBox/Component Pascal. o Modular o Garbage collection o Great compiler that puts the cursor *at* the error in your text. o Development environment has compound documents for high quality publishable writing and the same document for source code. You can embed bitmap images to aid documentation of your code. o No make files! o No compiler switches! o No linker switches (no explicit linker)! o ABSTRACT and EXTENSIBLE data types for generalizable programming. o many other good features. Best regards, Doug Danforth

Entrepreneurs

[Anonymous Coward]

Most of my income over the past 10 years has been programming, usually freelance. I have no degree or other credentials so I only can work for people who already know what I can do, or companies small enough to be persuaded that I can get the job done.

I find that all entrepreneurs work more or less the same way - they don't know what they want, but they want it RIGHT NOW; then when you give it to them, they have no time to look at it. Their checks clear, but I'm pretty sure half my projects never even got looked at... which is just as well because they were mostly crap - no design stage, vague goals (frequently changed along the way), and under-tested. Documentation? HAH!

Contrast with a research organization I was associated with, where instead of "We must do this fast or we will lose money" the attitude was "We must do this right, or all our conclusions could be wrong and people might die"... There, I had the time and resources to do the job, and my employer knew what they wanted - and tested what I gave them to make sure. Stuff I wrote 8 years ago is still running fine. Documentation written, but never needed.

So, I'm proud of SOME of my code...

80-character limits

[Anonymous Coward]

If you write your code and are afraid to go past 80-characters you are either i) nostalgic or ii) old or iii) think that 80-characters per line is cool or hell, all of the above.

Seriously, does limiting yourself to 80-characters bring you back to the disco era (remember long hair, sandals, and leisure suits)? Or maybe you still use punch cards? Eighty characters is definitely less than half of the way across most modern screens if you haven't noticed. Oh wait, you might want to print out your code! Again, symbolic debuggers have been around since the 1980s (at least for most modern operating systems). Blah, blah, blah...

Merry x-mas and buy yourself a new video card that can sport up to 132 characters per line!

Re:80-character limits

[Anonymous Coward]

Modern screens are not limited to disco-era 5x7 fonts. There's a reason nobody in the publishing industry makes readers try to track one of many endless lines of text. They long since figured out that ten words per line is about optimal. 160 characters is nearly three times that far, which sounds literally painful.

Get yourself an LCD or two, crank text up to something actually legible at native res (hold open a magazine--text onscreen should be bigger than that, as it's normally read from farther away), and welcome to the world of antialiasing and kerning.

Yes

[Anonymous Coward]

To actually answer your question:

Have any developers here successfully lobbied their company to stop or cut back on 'cowboy coding' and adopt best practices?

While I wouldn't say "best practices," I did work at one small company where me and another developer were able to convince management that we needed to have some standards in the way we wrote code. The company was a mess and often lied to our clients about what we could produce, but we were able to make the job significantly more fun and produce significantly better code by implementing some very basic things. We got them to start using source control. We were able to get them to let us write better and reusable code by convincing them to start using some basic "agile" development. Customers really appreciated having periodic drops (milestones) of what we were working on to make sure it was going in the right direction, for example. But we had to put forth the business case before we could convince them. That's the biggest thing. It has to make business sense.

controversial coding

[nerdyalien]

I am not a software programmer, just an engineer who is familiar with number of programming languages.

Regardless what language, I usually try to do first is to get the requirement and write a very controversial, uncommented, messy code which fulfills the requirement. Once its working perfectly, I investigate the ways to improve its performance in whatever ways possible and make a finalized version with comments.

Back in my uni days, one assignment was to write a MIPS emulator (for a large pool of commonly used instructions). Others were wrestling with neat codes while I highly insisted on the accuracy and reliability of the code. After 2 weeks of double shot espresso, I developed a perfect emulator, which later selected to share at the Uni server as a reference. Of course I did lot of finalizing (commenting, renaming variables etc.)

I was quite scared at first, as many would not understand my code (because many were using this to the follow up assignment, losely based on this code). But... astonishingly, people didn't find it a big issue at all.

So.. some of my experience in bullet form

- write simple code, forget about bringing complexity as its not gonna help you when things go large.
- use as many as functions/classes.
- name variables with common names rather with encrypted security code.
- first concentrate on the reliability of the code, make it work.. then think about how to improve.
- rule of thumb "less complexity, less things can go wrong" (this is why many GT cars are electronically not fancy)

Always the others

[Anonymous Coward]

You could for one thing start not using the excuse that everyone around you is not acting as expected and start writing quality code (what ever that is...) and not worry so much about what other people do. I see this behavior every day at work, someone puts something together saying, It sucks but so does the rest. That way of approaching things are wrong. I the old two wrongs doesn't make a right. Do your best even if it only a few functions or methods on a class - it better than just following the flow of bad code. What I'm trying to say is, don't follow the flow do the right thing yourself, use best practice and others will follow you.

Functions, functions, functions.

[Anonymous Coward]

It's inevitable that some of your code will be sloppy. Not everything deserves to THE FASTEST IT CAN POSSIBLY BE. First of all, that's what optimization is for, and there's a reason to do that last. Trying to get too fancy too quick means mistakes. Second, much of any program is going to be pretty trivial stuff. An hour spent prettifying an unimportant function is an hour not spent fine-tuning a mission-critical function.

That said, there are always going to be times when you have to go back and make some of that horrible code elegant. Or worse, go back and rework someone else's code. The SINGLE MOST IMPORTANT THING is function documentation. Every function you write, sloppy or otherwise, should specify

1. General, high-level, informal stuff:
    a. What it's supposed to do in simple terms. (More mechanical descriptions should be inside the function, generally over control statements)
    b. Where this function is intended to be located in the program flow (esp. what functions call it and what functions it calls)

2. I/O:
    a. What its inputs are.
    b. What its output is.
    c. Acceptable values for both.

3. Potential tripups:
    a. Any external side-effects or dependencies (setting a global variable, destructive behavior, RPCs, etc). (Ideally the answer to this would be "none" in almost every case.)
    b. Brutal kluges (AKA the ubiquitous "fix this later" list)
    c. Known problems

Functions written with even 2(a)(b)(c) and 3(a)(c) on that list should not only be trivial to test, but more importantly, it means that if you need to scrap the function and start over from scratch (which, let's face it, happens a lot), then in theory you should just be able to delete everything after the declaration and write a new function that does exactly what the previous documentation says it's supposed to.

Any code that describes its functions this way and uses reasonably descriptive naming conventions should need little in-line commenting. I generally don't worry about sloppy code, I worry about code that works and is maintainable. Even my own code often looks incomprehensible to me 6 months later if I don't follow good function-documenting practices.

We should always approach good coding like we do good writing -- tell 'em what you're gonna say before you say it. If you can do that, everything else is a breeze.

Calculated GOTO's are beauty!

[HornWumpus]

Almost as good as pointers.

CS is a science? First I've heard. I treat the whole thing as an engineering endeavor.

Uh ...

[ScrewMaster]

I am downright embarrassed by the quality of my code. It is buggy, slow, fragile, and a nightmare to maintain. Do you feel the same way?

Well ... no.

I'll be the millionth person to disagree here...

[Mongoose Disciple]

The interesting thing about commenting is that it's very hard to teach in a classroom, mostly because it's hard to give students a project in which it's really important. (OOP was the same way for me, honestly... in college it seemed like extra hoops to jump through for no real reason because even a 'big' project you do for a class pales in comparison with the kinds of things you work with in the business world.)

The first time I had to maintain someone else's code and didn't know what they were trying to do, I thought I finally understood the reason to comment code.

The first time I had to maintain MY code a year later and didn't know why I had written it the way I did, I really did get it.

Writing clean, readable, self-documenting code is important, of course. Writing a pile of comments is no substitute for it. The limitation is, even the best code only enables the person reading it to know what the code does. It doesn't convey intentionality.

If something seems like it's written in a backwards way to me, was that done because the programmer didn't know better, or because of a reason it really needs to be that way that the original programmer knew but I don't? What if the code is right in a certain set of circumstances, but makes some assumptions that now don't pan out? What if the code was right five years ago, but now the business rules have changed? (Or worse, what if they've changed for half of the business that uses the program, but not the other half?) What if what seems like a hack turned out to actually be necessary for the program to reach its performance requirements? I've seen all these situations and more constantly.

Comments aren't there to help me understand what the code you wrote does if you wrote it well; they are there to help me understand what you were thinking when you wrote it, so I'll know how I should change it and why.

Been there, conquered that.

[Anonymous Coward]

I once felt the same way, but then I found a company where failure was not an option. If your code wasn't good enough, there was a seniour developer there to take over, if you failed to complete your assigned task, someone else was there who could do what you could do in a month in a single day. Failure is not an option - find a way or find a way out.

Its an interesting way to do work, but in the end, you end up with a decent product which has many bugs, but not many critical ones.

Difference between junior and senior

[Anonymous Coward]

Actually, I encountered this very conversation at work today.

There is a differnece between a junior and a seniour software engineer. While the junior engineer sees the senior as unable to recognize the "brilance" of unit tests, the seniour engineers remembers his folly into unit tests and recognizes only the stupidity of unit testing with disregard for the whole - unit tests are only that. Ultimately, it is experience that matters, and no matter how smart, clever, or cute a solution is if it has not experience behind it it is ultimately horse patutity.

Nah I always get fired now for enforcing standards

[Anonymous Coward]

Before end-of-2006 I had always won these arguments, or not taken the job to begin with. Now I am facing 1/10th of the hours needed for critical financial applications, violating copywright law specifically with GPL licences, and long hours of free work in the promise of new paid projects.

All of these things I have said no to in the past and won, since 2006 I've lost every client or job for trying to enforce business law or standards. What gives? It hasn't been this bad ever and I've worked 11 years in SF developing websites and intranet applications.

Commenting the code??

[madbawa]

More often than not, I've seen people putting in comments that explain the code:

int i = 1; //initialize i

I mean, what sense does that make?? The mistake most programmers make is they comment the code and not the intent of the code. Some people write the code first and then comment it. Often times, the actual algorithm doesn't reveal itself at all in these comments. The reader keeps wondering what the hell is going on. I have tried to understand one such algorithm that used several different heuristics for accomplishing a particular purpose. The "code" for this function was more than 1000 lines and it was sparsely commented. It outlined the "intent" of what it wanted to do. But the code was too darn confusing. The sheer amount of variables that were used made it very hard to actually keep in mind what was going on.

What I have learned is that you cannot "understand" code that is written by someone else and is complicated. You will be limited by your intelligence in trying to understand that code. The only thing you can do is fix some bug that may arise.

Sometimes

[RAMMS EIN]

I am proud of some code I have written, ashamed of other code I have written.

I hold all code to the standard of elegance. I think elegance is largely a matter of taste, but there are absolutes. Repetetive code is not elegant. Large blocks of code are not elegant. Special cases are not elegant.

Recently, I have been getting the impression that whether the code I write is elegant mostly depends on the circumstances. Given enough freedom, I will write elegant code. When constrained by the language, time, or the code I have to interface with, my code often comes out less elegant than I could wish.

The ugliest code comes when (1) the language does not provide powerful enough abstractions (which I could use to contain the mess), (2) the library I have to work with is buggy, and (3) I am pressed for time. I guess the process is somewhat like this:

1. Use trial and error, and copy-pasting from the 'net, to write lots of snippets of code, until you hit one that works.
2. Copy-paste that one and adapt it to all places you need something like it.
3. Be happy that it seems to work now, and hope you never have to deal with it again.

Whereas my normal coding flow is something like:

1. Review the requirements and available building blocks.
2. Design a solution that implements using the available building blocks.
3. Look for patterns you can abstract from and code that can be re-used.
4. Implement the solution with a minimal amount of self-documenting code, with comments in the parts you can't make self-documenting.
5. Document what you've implemented, why, and how others can use it.

Look ma, no comments !

[Anonymous Coward]

At our shop we would add the member function below. We would also add some (unit) tests. It's more work, but in the end the quality and the maintainability of the code is higher. Note that code like this is automatically inlined and that there won't be a performance penalty.


void InitializeToOppositeEndsOfRange(ref int nIMin, ref int nIMax, ref int nJMin, ref int nJMax)
{
      nIMin = m_nIMax;
      nIMax = m_nIMin;
      nJMin = m_nJMax;
      nJMax = m_nJMin;
}

The art of commenting

[rjwoodhead]

Obviously there is a balance to be had when documenting your code. For me, commenting is a literary endeavor; good comments should explain exactly what the code does, explain anything that's non-obvious, proudly point out your brilliant insights, and own up to any sleazy hacks that you were forced to perform - and do so in an elegant and entertaining manner. The ideal comments are those that allow your audience (even if it's just an audience of one, you) to understand what your code does without boring them to tears. This helps the comments do what they are supposed to do: explain what your code does, and reduce the number of "WTF?" moments your readers have (it is particularly embarrassing when you are the reader going WTF?!). They will also remind you, when maintaining your code, of both your mad skilz and the stuff you really need to make more refined before anyone else sees it and thus realizes what a kludgemaster you really are.

As a rule of thumb, you should probably have as many comment lines as code lines, but they will be clumped in particular areas. Of course, YMMV.

A bit OT: a previous poster wrote: "And each time I see those nuggets of perfection, I snag them. They get added to my pile of code samples for later use. Either in a straight copy or as a foundation of an idea that gets recoded, depending on license requirements."

This reminded me that old programmers don't write code, they just remember it and type it in again. Though I doubt I'll have to remember any 6502 code anytime soon, a pity since it was such an elegant little instruction set.

Best,R

I like my soul, thanks...

[Icarium]

... and by writing crappy code and assuming all other code is crappy, I can avoid both Pride and Envy. Two deadly sins down, 5 to go.

Mass never changes?

[Anonymous Coward]

That should really be getRestMass() since the apparent mass will change with the relative velocity of the observer.

But then if you put the ball into a subspace field, the inertial mass will decrease, so it should really be getRestGravitationalMass()

I disagree

[IBitOBear]

(Mis)Using enum to introduce constants is _evil_ (IMHO of course) since you are poluting the global space but you aren't providing any kind of certian type info. That is, you don't know the size or signed-ness of an enum element.

scoped constants are why god invented "const"...

Which is cleaner and more clear:

enum {
      Target = 8,
      Repeat = 17,
      Factor = 16,
      Fault = -1
};

or

const unsigned int Target = 8;
const unsigned int Repeat = 17;
const double Factor = 16;
const int Fault = -1;

The explicit typing (in C++ and ansi C, the enum above is possibly a signed char) and the removal of "bogus" associations Fault and Factor don't necessarily have a relationship to Target or Repeat, so why are they in the same enum? What would be the increase in clarity if they were each in a single element enum?

See, even you have bad shortcuts in your standard approach...

Nothing I wrote for money is worth a...

[grikdog]

...single neuron out of Spock's brain. Some of my private code is downright pleasing, although revoltingly non-commercial. When I was (*ahem*) "coding" — HR geekphreeze for munger wrangling that translates more or less 103% correctly as "less money than programmers get," just as HR learned very early on that "programmer analyst" is $35,000 more per annum than "programmer" — back in my shrinkwrap daze, I always felt my stuff was three weeks too premature for genius. Deadlines. It's worth noting that NOT ONE LINE OF CODE that was commercially successfully for that company (long since gutted by a buyout during the Dot Com shakedown) was ever written in-house.

Take small, meaningful steps

[Twylite]

I have worked at several companies where I have had to drag the team into following some sort of agreed practice. I'm not saying a "best practice" because hardly anyone has metrics to prove that their practice gives them a competitive advantage. I'm not even saying a "documented practice" because that would be asking too much. This is more of a "gentleman's agreement" on the minimum level of work that will be accepted.

In my experience any change you propose will face resistance from your co-workers and management if it appears to involve more work. This means that anything you try to introduce must have a clear and immediate advantage that actually reduces workload (and/or reduces cost).

Straight off the bat you can forget about coding style. It's where most practice-mongers start, and it's why most attempts at introducing "best practices" fail. No only do you force your team into a religious conflict, the benefit of a Single Enforced Coding Style is marginal (and there is academic research to back that up). Once you have buy-in for the value of practices, introduce two simple rules to handle coding style: (1) within a file maintain the style; (2) don't restyle an entire file (it wastes time and makes version diffs impossible, especially if everyone starts doing it).

You can also forget about taking the stair machine to Agile. You boss and peers aren't going to buy pair programming or that amount of unit testing (and certainly not writing the tests first).

Step 1 is to introduce source control. Use something Really Bloody Simple. Visual Sourcesafe if you can. Subversion with a GUI client if you can't. Don't restructure projects to make them play nice with source control; don't use branching and all the other advanced crap. Stick to the basics. Check out, change, check in, tag/label occasionally. Focus on the value proposition: everyone has access to the code, the repository is an "extra network copy" in case your development PC crashes, and you can diff between versions which makes finding out what you broke REALLY easy. Tags/labels allow you to easily find the last known-good build.

Step 2 is to introduce MINIMAL documentation standards. Encourage developers to put a one-liner at the top of each function saying what it is _intended to do_. Then state what it is supposed to return. That's it. Anyone maintaining code will see the value of this level of documentation very quickly, and will start bitching at developers who fail to document their functions. Point to you.

Step 3 is to introduce DBC (Design By Contract (TM)), or part thereof. DBC is IMHO the first step to bug reduction and improving the ease of debugging. Every function must be able to return a valid answer or an error, and must start by checking all of its parameters. EVERY function. Even that inner inner loop that has to be fast because otherwise the universe will end. If you were working on something that really had to be that fast, your team would already be using Best Practices. A Lot. Whenever you call a function, check for errors. Never assume that the function call succeeded even if you Know Deep Down that it Cannot Fail ... because It Can.

Another way of looking at this is to remember that every CS 101 course says "check input parameters". You should do so in The Real World as well.

Step 4 is to create a culture of unit testing. But do it right. Test as LITTLE as possible, but test the most likely to fail conditions. Most people write unit tests starting from the simplest cases and working up; don't waste time, go for the jugular. The intermediate cases help in debugging, not in regression testing. If the worse possible cases (especially corner cases) chances are good that the rest works too. Good enough that you're wasting time testing them unless you have a big budget and lots of staff.

If developers resist unit testing, hint subtly that it is a convenient way to shift the blame to others. The unit test on YOUR code fails, so this i

I highly recommend critical review.

[Anonymous Coward]

Whether you're writing C, assembly, or one of the many other languages, it helps to get critical review from other more experienced programmers. Most of the time when you're starting out it can be brutal. You may find you don't want to be a programmer/designer, but don't give up. That pain is just your mind expanding, and adapting to the thousands of patterns involved.

Becoming a good programmer is much more evolutionary, than revolutionary. It's about doing more with less, and making that less be correct. It's about testing, and interactive testing. It's about using graphs or generating images for code that isn't easily testable with a regression test suite. It's about leveraging the language features for your own benefit, and combining them in new ways.

Code should read like a novel...

[Simonetta]

Code should read like a novel...The comments should be in paragraph form. The part of the code that actually communicates to the computer should be like dialog.

    You can't have too many comments. I like to place a photograph of someone attractive next to the monitor screen. I pretend that this person is somehow extraordinarily interested in the program and how it functions.

    Then I use a speech-to-text program and talk about the code. Describe it from the beginning; what it does, why it is needed, and what is special about this code as opposed to the other programs out there that to more-or-less the same thing but not as well as your code. Talk to the photo. It's a fraud, it's a little pathetic but ignore this feeling. You are creating comments.

    You end up with a lot of speech converted to text. Break it into paragraphs of a few sentences each. Place each paragraph between one or two of the actual lines of code. Try color coding the comment paragraphs differently from the code. Try recompiling the actual compiler so that the code must have a special character or pair instead of the comments. A double quote char for the actual code is good because it makes the code look like actual dialog.

    Our coding style comes from the long-ago days fifty years ago when memory was extremely expensive and programming talent was relatively cheap. The opposite is true today. The great thing about speech-to-text is that it allows people who hate to type but love to talk to be able to create extensive and valuable documentation. Remember that it is easy for your 'reader' (that is, the next person who will be studying your code in order to modify or improve it) to read quickly or skip over the paragraphs of comments that are overly long. It's much easier to skip over excessive verbage than it is to try to understand what the previous coder was actually trying to do with dense code.

    The more advanced and powerful the computer, the easier it should be to write programs for it. The computer should be doing the work, not the programmer.

    C language is junk and obsolete. We only use it because we spent so much time learning it. We invest billions of dollars making an ARM microprocessor that runs at 80 MegaHertz, has 128K of Flash memory, and costs only $5. But we won't invest billions of dollars to make a simple programming language. So we're stuck with C. It's a trade off. Luckily for our grandchildren, they won't have to bother with it. Just like our children will never have to deal with typewriters or Morse code.

    White space sucks. It's source code, not avant-garde poetry. It should read like a book. In the future, writing code by itself should seem as strange as adding long columns of numbers seems today. But 100 years ago, people made good money doing it. Probably better money than you make now writing code.

    Thank you.

sometimes

[burdalane]

I'm proud of some of the code that I've written because it's modular and reusable, does something cool, or successfully implements a cool idea that I came up with. But sometimes I'm proud when I manage to write anything that doesn't crash immediately. At my work I mostly code alone, and there aren't any organization-wide best practices policies. Since it's a research institution, satisfying all the customers 100% isn't that vital to the bottom line.

Get the customer involved

[lazy b]

I almost always have a good laugh after when I look at the code that I wrote some time ago. Which I guess is a good sign; it means that I've improved in the meantime. On the other hand, I've been in the happy situation to see most of my code go into use; some of it is still being used 8 years later.

Learning different languages seems to help me write better code in any given language. It's something I do as a hobby (this has the (un?)fortunate side effect of making me less and less fond of PHP, the language I use most at work).

At work we've recently switched to agile project managment (scrum), and now the first big (7 month) project using scrum is done. I have the feeling that the process really helped. We did change course a couple of times, and some pieces ended up being done with other applications than those originally planned. We demonstrated what we had working to the customer at the end of every three week period, and discussed what was most important to do in the upcoming three weeks. Because of this tight feedback cycle, we didn't go (too far) out on wild goose chases. And the customer was extremely happy because he knew what was going on. And because he knew what was going on, he understood when we said that implementing such-and-such feature or making such-and-such change is of course possible, but not without cutting some other feature or increasing the budget.

It's a bit of a change for the customer, and they will spend more of their time on the project than with a project using traditional project management, but the end result is better (from my experience and from what I've heard).

No

[QuasiEvil]

Am I proud of my code? Not necessarily. I can't tell you exactly what my baby is, but suffice to say it's the core scanning/routing logic of a Fortune 500 global transportation company. Part of it's an ugly piece of crap - well, actually a lot of it is. But it works and works reliably and is maintainable, as evidenced by the fact there have been two maintainers before me and two since.

What I am proud of is the architecture (compression algorithms, general data table design, etc.), as well as parts of the codebase, are approaching twenty years old and are still running in nearly 700,000 devices and performing some 120 million barcode scans each and every day. In that fifteen years, we've had only two days of total global outage, despite the fact we update and augment the data file monthly and there are dozens of legacy versions of the code running in production, with untold numbers of bug landmines just waiting to be stepped on by new data. I'm proud of what it enables my company to do, not of the code itself.