loading...

Discussion on: What I hate hearing most as a developer.

michael profile image
Michael Lee 🍕 Author

Michel, if you've got some tips on how you do this, it'd be great!

Thread Thread
metalmikester profile image
Michel Renaud

I'm not saying I'm working any miracles here, but I've rarely had people come back to me after taking over code I've written:

In separate documentation (e.g. Word document, whatever):

  • High-level explanation of the system, maybe down to the module level (depends on the application...)

  • Doing anything really weird? Explain the madness without getting too much into the implementation details. For a recent project, I was getting input from a query builder and generating and executing C# code on the fly (using Roslyn). There were some tricky parts and it's not obvious from just looking at the code, so I explained the flow of things.

In the code, I used to be big on comments, and I still write them, but less. That's after realizing they often went out of sync. So, variable and method names as descriptive as possible. No Hungarian notation garbage, no dropping the vowels in identifiers, etc. If something is weird or a workaround (sometimes to address a bug or shortcoming in a library or framework), then I'll document that. I just did that this morning for a workaround I had to do so something would display properly in a specific browser. That will save future generations from wasting time trying to do that tiny part the same way the rest is done.

I'm sure there's more, but as you can see it's nothing out of the ordinary. Just experience built over 31+ years of frustration doing this kind of work, for the most part. :D