tag:blogger.com,1999:blog-5933717644607161038.post5183368711836998281..comments2010-02-17T07:44:02.164-08:00Comments on Genne's Blog: Dedefending my case: Stop documenting your code!Christian Gennehttp://www.blogger.com/profile/05183435846100768676noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-5933717644607161038.post-19587366910679685352008-04-03T23:04:00.000-07:002008-04-03T23:04:00.000-07:00Thank u! Nice comments :) Some response to your co...Thank u! Nice comments :) Some response to your comments:<BR/><BR/>* Labeling your code is not wrong, it's actually a nice way of using syntax highlighting to divide the code. But in most cases you can simply extract the labeled blocks into new functions, can't you?<BR/><BR/>* Coding conventions have some specific pros according to me: 1) No one will get annoyed because some code is formatted ugly according to them. 2) Code will look the same all over, and thus you don't get the feeling of code being written by different independent coders. 3) When you get used to a convention, you will understand the code faster!<BR/><BR/>I actually <B>do</B> think that many coding conventions (CCs) in larger projects cover if you should write your code in lambda- or OO-style. Of course, CCs change over time (suddenly you could write lambda-functions in C#!), but you also need to respect them. Don't write lambda-style if the CC doesn't state you should, because some of the programmers might not be used to this style of programming.<BR/><BR/>And as you said, coding conventions are just a set of regular expressions, which is good because then you can write a program that analyzes your code to make sure it follows the rules! :)<BR/><BR/>* Statical analysis is a very nice complement, but then you need to know what code complexity really means :)<BR/><BR/>* I agree that you should comment algorithms. Even if you put them in there own functions describing what they do, you should write comments on <B>how</B> they work. Actually, in all cases where your code is hard to get, and there is no way to refactor it, you should add comments!<BR/><BR/>* I don't have so much more to say about buisiness-logic coding, you already said everything that is needed to know :)<BR/><BR/>* Yes, you really should :)Christian Gennehttps://www.blogger.com/profile/05183435846100768676noreply@blogger.comtag:blogger.com,1999:blog-5933717644607161038.post-52727136724420161952008-04-03T02:42:00.000-07:002008-04-03T02:42:00.000-07:00Nice post! I agree on most of your thoughts, some ...Nice post! I agree on most of your thoughts, some comments though..<BR/><BR/>* Dividing your code blocks with commented "labels" seems pretty harmless, just to show a division of concerns. Though, if the method shouldn't be too large.<BR/><BR/>* Coding conventions is basically just a set of regexp rules. It provides a bit more readable code, but I think manual inspection meetings are a good complement for this. For example (in C#) your boss could have hired a crazy functional programmer that rather write lambda-calculus than regular OO style. Traditional coding conventions would not cover this.<BR/><BR/>* Statical analysis (i.e. code metrics) could be another complement, i.e. a McCabe Complexity value above 40 would indicate that something fishy is going on. If you reduce complexity you can remove unneccesary comments as well<BR/><BR/>* Algorithms should be well encapsulated in classes/modules and well commented, I think. Dynamic algorithms can be really tricky, but hey even old Dijkstra's algorithm is not trivial.. :)<BR/><BR/>* Business logic should probably be written in a "higher level language" (interal/external DSL, workflow, BPEL, etc..) because business logic tends to change in a higher frequence than other code..<BR/><BR/>* I should really start my own blog.. ;)Gustaf Nilsson Kottehttps://www.blogger.com/profile/06265015751619707522noreply@blogger.com