A long time ago (but not in a galaxy far away) I bought a C cross-compiler from a small company in Newcastle, in the north-east of England. I travelled up there (about a 4 hour drive each way) and spent a couple of hours while they demonstrated their products and I decided what to buy. I left with the software (on a few 5.25" floppy disks) and a few A5 ring binders with the manuals. The C compiler ran on an 8085-based Microprocessor Development System and targeted code for an 8080-based custom controller that I had built myself.
Among the manuals was a rudimentary C language reference which included a few pages of what we would now call a Style Guide. That included a sentence that, even after all these years, I can almost remember word for word: "Nothing in this section affects the way the program works and you don't have to follow any of these rules but these high-handed dicta have proved their worth time and again." Having never programmed in C before I followed the guidelines carefully and now (more than 30 years later) my coding style is still based on the same standards. I have changed little other than to add more rules in the same spirit (to suit C++ and C#) that I impose on myself with equal rigour. I subsequently discovered that some of the style in that guide is quite different from K&R and I still firmly believe that in those places K&R were wrong!
I often think about the unknown author of that guide and how much I owe to him or her. I lost those little black plastic binders a long time ago but I will never lose what their contents taught me. Thanks a million, whoever you are!
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
When I was learning OO, I found Booch and OMT very useful. There was another very good book on cue card method of OOD, but don't remember the name.
For UI design, I was really impressed by Alan Parker’s "About Face"
I picked this book up after programming for 20 years. It's a truly wonderful book about practical software design and implementation. I found it almost shocking how all of the new 'movements' in software development were all in here.
Iterative development, clean interface decoupling, etc.
While the "design pattern/pattern language" javalicious object everything approach has some gems in it.
I started to learn programming with C then switched to C++.
But it was a book about programming in Java (I cant remember the title) that was the most influential to me.
That book really showed me a power of OOP and good design patterns.
Since then I always have this nagging notion of an elegant code in my mind .
Previous -> Read "CLR via C#" by Jeffrey Ritcher.
Current -> Exploring WCF thru Apress' "Pro WCF" by Chris Peiris and Dennis Mulder.
Next -> Need to read "The Art of Computer Programming" by Donald E. Knuth.
I learned to program in assembly, the programs we wrote were for troubleshooting early IBM PCs. The two processors we wrote for were the Z80, the Intel 8080 and the 8086. I still have my Understanding Microprocessors text book from 1993 that covers the Intel processors.
I still use assembly today for Freescale (Motorola) HC08 microcontrollers.
A lot of strictly technical books here. While I agree that they help making you a good coder, they not necessarily teach you the intricates of the trade. How to deal with difficult projects, how to manage unreasonable expectations and how to fight for your personal time are as important (if not even more important) to being a good PROGRAMMER. That's why I recommend "The Career Programmer: Guerilla Tactics for an Imperfect World".
Sorting by frequency of occurrence isn't very useful. It appears a search for an exact title match is being done. As a result, the count for Niklaus Wirth's "Algorithms + Data Structures = Programs" is incorrect.
Besides it is a 'Manual' for learning C, it IS (and not only WAS) a great book to learn how to program in a right way. It is easy to understand. (OK, the writing is easy, the concept not too much for beginners) but if you start form the beginning and read each line, you will learn how to make good programs.
We have three things in common. One, the book we used to learn to code. Second, I also started on 68000 chips (Amiga 1000) and third, my second lastname (I live in a country where we use 2 lastnames, father and mother) is Clement. Germán Valencia Clement. And yes, German in Spanish is the same than Hermann in English lol.
Great to know you German! It's cool that we share so much. My first computer, by the way, was an Amiga 1000 (unless you count a Sinclair ZX80). I wrote a freeware program that appeared on one of the first Amiga freeware disks (it was called "enpig" I think.) I searched for it, but it seems to have been erased from the memory of the internet. It took in a typed English sentence, parsed it (badly), converted it into Pig Latin (e.g. "That was fun" -> "atthey usway unfay") and spoke the result using the Amiga text to speech feature.
This is excellent! Nice to meet you too Mr. Clement .
I worked for an engineering company at that time, and I wrote my first program using C for calculations and AmigaBasic for the interface (it was easy to work with it for windows and buttons). That ancient program was for calculating steel structures by matrix inversion methods.
We use that program in Amiga and not in PC compatible, because it was easy to access all the memory (4 MB RAM) and in the PC environment was a very difficult task. (At least in C or basic). That program never was sold and it is not possible to find it in Internet. And sadly, the source no longer exists.
Very true. Some (actually nearly 30) years ago, I was given a new project at work and told that C should be the language of choice. I read this book over the weekend and started coding on the Monday, and was surprised at how much this book helped me.