Blog of Leonid Mamchenkov

Here is a quote from a wise comment in the discussion of the “Linux system programming” book review:

Build your code with -Wall -Werror (or your compiler’s equivalent). Once you clean up all the crud, that pops up, crank it up with -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith. Once there — add -Wreturn-type -Wcast-qual -Wswitch -Wshadow -Wcast-align and tighten up by removing the no in -Wno-unused-parameter. The -Wwrite-strings is essential, if you wish your code to be compiled with a C++ compiler some day (hint: the correct type for static strings is ” const char *”).
For truly clean code, add -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls.
The people, who wrote and maintain the compiler, are, most likely, several levels above you in understanding programming in general and C-programming in particular. Ignoring the advice their code generates is foolish on your part…
As a minimum, solved warnings will make your code more readable by reducing/eliminating the “Why is he doing this?” questions. More often than not, they point out bugs you would otherwise spend hours chasing with a debugger later.
And they make your code more portable. But if you don’t understand, why a warning is generated — ask around. Don’t just “shut it up”. For example, initializing a variable at declaration is usually a no-no. If the compiler thinks, the variable may be used before being initialized, scrutinize your program’s flow. If you can’t figure out, it may some times be better to disable this one warning temporarily with -Wno-uninitialized to move on, instead of shutting it up for ever by a bogus “= 0″ or some such…

Steve Yegge has posted yet another of his excellent (and long) rants.  This time he talks about the size of code and why one should jump out of its skin to keep it minimal.

 Most programmers have successfully compartmentalized their beliefs about code base size. Java programmers are unusually severe offenders but are by no means the only ones. In one compartment, they know big code bases are bad. It only takes grade-school arithmetic to appreciate just how bad they can be. If you have a million lines of code, at 50 lines per “page”, that’s 20,000 pages of code. How long would it take you to read a 20,000-page instruction manual? The effort to simply browse the code base and try to discern its overall structure could take weeks or even months, depending on its density. Significant architectural changes could take months or even years.

As I said, it’s a long piece. But it’s worth every paragraph. Even though some Java programmers might be slightly offended by the article, I’m sure it’s not intentional.

In the last couple of days I repeated this more than four times, so let me post it here for any future references.

Two points for those who want to become a programmer.  First, there is no lack of information these days. There are numerous tutorials online and books in print.  There are magazines, classes, mailing lists, search engines, and everything and anything you need.  But all that information won’t make you into a programmer.  In order to become one, you have to program.  There is no way around it.  You have to design your programs, write the code, debug it, test it, document it, and maintain it.  And you should also read good code that other people wrote.  There is no lack of open source projects these days - take the most popular ones and you’ll learn a lot.

Secondly, among all those available resources, I can suggest two books and two books only.  If you read and study both of them, you won’t need to read another book about programming your life time.  The first book is “The C programming language” by Kernighan and Ritchie.  This is an all time classic.  The second book is “Programming Perl” by Larry Wall.  This is a piece of modern literature.