The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
I'd like to make a crazy proposal: When Intel presented its iAPX 432 CPU, I got hold of its reference manual. It is certainly not a programming book, yet it is about what we think of as programming. It made me thoroughly rethink the distinction between hardware and software - as well as some important software concepts.
E.g. in the 432, if one process sends one of its objects to another process (using the IPC instructions of the processor), the sending process looses that object. It may of course make a copy of the object before sending the original away (or keep the original, sending a copy), but the original and the copy are distinct objects. If you give one of them away, you give it away. That is how things work in real life, and in the 432, but not in commonly used software systems today.
Even though the 432 was a major flop, its reference manual has significantly formed my ideas about software. And hardware.
When looking for basic algorithms, you can't do much better than Knuth. For specific programming languages, I prefer Plauger's The C Standard Library, Alexandrescu's Modern C++ Design, and anything by Steve McConnell or by Charles Petzold.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
I'm not one for books, but if I had to pick one (besides my own, of course) I'd go with Robert C. Martin's Clean Code.
That book changed the way I write and think about code.
The beauty is that it applies to all languages that were, are or will ever be used, although it uses Java for examples.
Come to think of it, if a Java book is my favorite it has to be REALLY VERY GOOD!
In all seriousness, I adopt a more relaxed style for my personal projects versus my professional projects.
The thing is, after years of confining myself to the house style (whatever shop i'm at) working my own way is liberating. Maybe I'm a bit extreme about it.
The other thing is, and maybe I shouldn't admit this here but I often am not thinking when I'm writing code. It just comes to me, and I let it. I've written some of my best code that way, so I don't fight it, but it's a bit like free association writing so it's going to reflect my underlying style preferences.
I adopt a more relaxed style for my personal projects versus my professional projects.
"We are what we repeatedly do. Excellence, then, is not an act, but a habit." —Aristotle
I couldn't even adopt a relaxed style if I wanted to.
I have one style and it's as relaxed as can be.
And I've used this style in multiple teams and I never had complaints.
Well, no complaints on my style at least
honey the codewitch wrote:
I often am not thinking when I'm writing code
So consistent with your posting here?
But seriously, if single-line if-statements are your worst crime you're doing a pretty good job!
I've seen 100+ line functions, 3000+ line classes (WinForms even), completely absurd and ridiculous database designs that weighed the whole project down, etc.
In that perspective, style really isn't that important.
I was going to say Clean Code by Robert C. Martin but Sander beat me to it, so I'm gonna go with Specifying Systems by Leslie Lamport. Not only is it a really interesting book but it's also pretty good for brushing up on discrete mathematics.
Haha, I haven't read anything else by Dr. Lamport but this book was excellent. I feel like this topic (discrete representations of software systems including liveness, safety, and fairness properties) is one of those topics where in 10 years there will be some testing framework that will allow you to verify code against a specification which has itself been mathematically verified for correctness.
There are some companies that have already used this concept for products (CosmosDB) but as far as I'm aware it requires manual verification of code against a spec which is tedious and time-consuming.
Not that I reading it anymore, but have a special place for my copy of PC Intern - System Programming by Michael Tischer...
It is about DOS so mostly irrelevant, but I've learned a lot about how to see things from that book...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
For nostalgia, I still have IBM's Guide to Operations, and Technical Reference, for the PC; which included a source listing of the BIOS, printer codes, memory addresses, etc. Now you just go and buy a chip.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
"Clean Code" by Robert C. Martin.
His central point is that most of the time you READ code, so you have to write it in a way that you can read it easily.
And he shows how to do this - and wrote the book in a way that you can read even the book easily.