TheCodedWorld

Recently we have been discussing coding guidelines at work. A topic that often pops up during such discussions are Comments. What should be commented, how should the comments be formulated etc. Personally I have the following preferences when it comes to comments in code: A comment should explain why  a piece of code does what it does, not what  the code does. If you feel a piece of code needs a comment. See if it is possible to make the code easier to understand rather than commenting it. Only use special mark-up like Doxygen if you actually generate documentation from it. I have seen cases where Doxygen-like syntax was used all over the code, only obfuscating the text. Public interfaces intended for users of your lib/class should be documented, and documented well. Internal/private interfaces and classes does not require documentation. Put effort on making the code really easy to understand rather than adding a bunch of comments. Keep comments short and clear. Happy comm

Now that I am working with development in C# I have started looking into some .NET specific stuff. Right now I am deep diving into Language-Integrated Query,  LINQ . LINQ can often be used to replace loops where you iterate over a set of values and perform some kind of operation on the values that matches a certain criteria. For example, assume you have a large set of random integers and you want to extract those that are divisable by 7. The standard way to solve this is to use a for-loop and copy the numbers where n % 7 == 0. With LINQ this becomes a one-liner: var divisableBySeven = (from i in ints where (i % 7 == 0) select i).ToArray(); Pretty neet.