Producing code quick is not the goal. The point is to produce well designed code that works OK, and that's easy to read/review/follow and thus to maintain.

I'm spending a lot of time on this because I've been working on a project for several months to revamp some PCs with 32MB of RAM to be sent to the homes of deaf people. I'm running a uClibc based distribution, but I need a good web browser which works. Thus I want to get this done as soon as possible.

The problem I found (and probably your classmates) is that reviewing rushed-code takes more time than necessary, and once understood, it changes. In my case is a bit worst because I took the extra time to polish it, only to find it back with my work wasted.

I crank out a lot of code because I think quickly and clearly, and have no life. If I could comit often enough, I could gurantee you about 4 hours/day solid development for the next month and a half. More if I dropped another pet programming project and some metal work I am doing. I am usually the person doing the code reviews. I'm also the person who tends to put the most documentation into my code to make the most redably readable.

Let me suggest you a second stage after your code is working. Stop, and take the same amount of time polishing it. Think of the design, long functions, multiple exit points, global variables, data structures, future additions, variable names, memory management, comments, etc.

Once you finish this second stage, testing for robustness will be much easier (third stage). Once you've done it, your classmates will love your code.

Most of my classmates can't program *snort*. Then again, neither can the comp sci professors.....

Just an example, multiple exit points make code more complex to grasp because you have to understand the flow of execution of each one of the exits, before having confidence of not breaking it with some changes.

I would disagree with that point. With single exit point functions, you have to carry a variable (extra stack allocation) through the application and all code. Thus you can either have large numbers of nested statements (which is very effective and reasonably clean, but excedes line length) or you have your finalized variable being carried through the rest of the application with nothing else to do. With the multi-exit point strategy, you can exit the application as soon as you are done done whatever it is that you need to do. This way you aren't hanging around in the code any more. I have found that tends to make for better code than single-exit writing.

Another big problem comes with finalization code (freeing memory, leaving variables in a stable state, return codes, side effects...).

Take for instance yes_ssl_support(). Look at the many exit points and its finalization code, and compare with a single exit code version.

It took a lot of time.

Please follow my advice.

Since this is the preffered coding standard (I suggest adding it to the coding standards on the web) I will follow it as you wish. I will follow any coding standards to the letter, and will take suggestions as I see fit. I will modify everything that I have writen to conform to your preferences, and resubmit. I'm tempted to blow away all of my work and start over sust so I can have a sync'd tree to make sane diffs against. *sigh* - Garrett