+1

I inherited some code that was a mess. The constructor on one class had over 140 parameters. Yup, each mapped to a column in the table. I replaced it with a simple DataRow.

As for comments, they should be used to explain weird things or when you have to do something out of the ordinary. Every dev should read Clean Code.

I'm going to be introducing FxCop as part of our build process later this year. I expect to hear complaints about that. But I'll bet it will be worse next year when I add StyleCop to the process.


>We all have, that's part of the learning process. I look at code I've written a year ago (after 30+ years experience) and shake my head wondering what was I thinking when I wrote that mess. The difference is that we, as competent programmers, solve our own problems (with the help of google first and advice second) not expecting someone else to do it for us and learning from our mistakes and not repeating them. The longer I program, the simpler my code gets. We had a guy here with us who has long since been laid off (nearly 5 years now and still out of a job). He was a master at obfuscating code, figuring that if only he could maintain it, that was job security. What'd the company do? Laid him off and hired someone else to rewrite the code in a more manageable style.
>
>I rarely write a method longer than 8-10 lines of code. I name things what they are and what they do. I don't care if the name is 200 characters long, it will describe what it does. I totally believe in the assertion that good code is self documenting. I rarely use comments after attending a session by one of my heroes. Jonathan Cogley, the founder of Thycotic, presented at a code camp and basically said, "if someone else can't figure out your code by how you name things and write it, then all the other stuff is meaningless". He said if you need to comment code, then you need to rewrite it so it doesn't need comments.
>
>
>Cheers..