Live data from Hacker News

John Carmack's comment on Doom 3's code style

kotaku.com

1–10 of 210 posts

Re: John Carmack's comment on Doom 3's code style

#3

My heart grew a little warm with the last paragraph of John Carmack's comment: "The major evolution that is still going on for me is towards a more functional programming style, which involves unlearning a lot of old habits, and backing away from some OOP directions."

Has anyone here come across any particularly good books or other resources on functional style programming in C++? Especially ones that have been updated for C++11s new functional features.

Re: John Carmack's comment on Doom 3's code style

#6
The author seems to like the minimalistic comments. I wonder if the team looked back what their thoughts would be. I can barely look at code I wrote a year ago and not ask what the hell I was thinking, but in my mind it was absolutely clear at the time. I guess an impartial third party reading it and understanding it is a strong testimonial.

Re: John Carmack's comment on Doom 3's code style

#7

My heart grew a little warm with the last paragraph of John Carmack's comment: "The major evolution that is still going on for me is towards a more functional programming style, which involves unlearning a lot of old habits, and backing away from some OOP directions."

John Carmack wrote a nice article about experiences writing functional code in C++ here:

http://www.altdevblogaday.com/2012/04/26/functional-programm...

Re: John Carmack's comment on Doom 3's code style

#8
I currently make a living by essentially applying these rules to other peoples code and handing it off.

My second programming lecturer ever, refused to correct my assignments if these rules were not followed. He never told us said rules though. This was before I learned what an array was! Got 0% on my first two assignments with him but eventually he corrected the next ones with a good life lesson.

Frankly its the only thing I remember from that asshole but was probably one of the most important lessons in my opinion!

Re: John Carmack's comment on Doom 3's code style

#9
Comments should be about why a piece of code does what it does not about what (should be clear from the function/method name) or how (should be clear from the code itself). As long as the comment just explains why it should be as long and detailed as necessary.

Re: John Carmack's comment on Doom 3's code style

#10
post #6

The author seems to like the minimalistic comments. I wonder if the team looked back what their thoughts would be. I can barely look at code I wrote a year ago and not ask what the hell I was thinking, but in my mind it was absolutely clear at the time. I guess an impartial third party reading it and understanding it is a strong testimonial.

The key is to have self documenting code, not undocumented code. If you create functions that do only a single thing, with their purpose fully described by their method signature then you don't need comments - the method itself explains exactly what it does.

The author makes a good point that comments are just more text that you need to maintain, and whenever you make changes you now have to make changes in two places: in the code, and in the comment - (and I guess in the unit tests as well, depending on the change...)

The best code I've personally seen has been code with no comments and an attached document explaining how the system works and how modules tie together.

Post reply on HN