Commenting code...
-
RCoate wrote:
I am always happy to err on the side of over commenting code than to leave something undocumented.
Documentation should not be done in the code. I prefer seperate technical documents. Everyone can hoover over Select (in our environment) to see what it does. Now it just adds clutter which I have learned to ignore because to often it does not add anything (see my post above).
It's an OO world.
Naerling wrote:
I prefer seperate technical documents
The 1970's called, they want their developer back ;-) If people rarely keep comments in sync with the code, the chance of them keeping separate technical documents is almost nil. Almost every project I've worked on with large amounts of technical documentation has been government contracts - badly run, badly designed, over budget and frequently failing, but I've not seen a single example of useful technical documentation on any project I've been lucky enough to work on. At least a comment stands some chance of being updated.
-
Last week I wrote a small library that would either startup a Form or focus an already open one, based on the Form you wanted to start. My boss wanted me to make a prototype that he could approve (approval can be reached by not using to much interfaces... He doesn't like them because it will make code harder to read and debug). So I was done writing it and showed him what I had made. First thing he said was that I didn't have comments in my code (well duh, he told me to finish it asap and he wanted to approve it first). So I had to put a comment above the Function FormCanBeShown that returns a Boolean. Yeah, what possibly could it do? Even better, I had the code
frm.Select
Boss: "What does this do?" Me: "It selects the Form... Basic Microsoft functionality..." *Hoovers over it to get MS IntelliSense prove of what I just said* Boss: "Well, I wouldn't know that, put some commentary there." And then the code looked like this:
' Activates the Control.
frm.SelectReally, was that necessary[^]?
It's an OO world.
Clearly, you should have given him a more useful comment, such as...
' Reroutes the neutrino flow through the primary EPS conduits.
frm.SelectProud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels) -
I am always happy to err on the side of over commenting code than to leave something undocumented. I have had to work on enough code that has been poorly documented to appreciate that stuff that may be ovious to me (as the author) can be opaque to another programmer who may have a different backgroud or skill set to me. You can go overboard with comments, but semantically (despite that this is standard MS behaviour), frm.Select does not suggest activation, it suggests selection. If you boss is from a different (programming) language background, the Select keyword could do something completely different.
RCoate wrote:
If you boss is from a different (programming) language background, the Select keyword could do something completely different.
I think the thing about comments here is that the Select statement is a standard .NET language construct. Therefore, you should know it if you program .NET. If you don't, you should look it up and then know it. Comments should be used for the non-obvious stuff, such as explaining (in short) an algorithm, or a couple of steps of code, or an (at first sight) unusual construct. At least, that's what I think. I'm a great proponent of commenting code though.
-
Last week I wrote a small library that would either startup a Form or focus an already open one, based on the Form you wanted to start. My boss wanted me to make a prototype that he could approve (approval can be reached by not using to much interfaces... He doesn't like them because it will make code harder to read and debug). So I was done writing it and showed him what I had made. First thing he said was that I didn't have comments in my code (well duh, he told me to finish it asap and he wanted to approve it first). So I had to put a comment above the Function FormCanBeShown that returns a Boolean. Yeah, what possibly could it do? Even better, I had the code
frm.Select
Boss: "What does this do?" Me: "It selects the Form... Basic Microsoft functionality..." *Hoovers over it to get MS IntelliSense prove of what I just said* Boss: "Well, I wouldn't know that, put some commentary there." And then the code looked like this:
' Activates the Control.
frm.SelectReally, was that necessary[^]?
It's an OO world.
Naerling wrote:
Really, was that necessary[^]?
I'm surprised your boss can read....
Sort of a cross between Lawrence of Arabia and Dilbert.[^]
-Or-
A Dead ringer for Kate Winslett[^] -
Looks like the biggest crime is that your boss didn't insist you comment why you were selecting the form rather than what the function did. I'm assuming there's a good reason you didn't use frm.Activate and your comment would be an opportunity to explain that to future readers. It can also be a useful technique to put down some comments first as an outline before writing the code. It doesn't take much more time and can even save time by allowing you to concentrate on the outline of a function before getting involved with the code.
Nah, he just "wants to see green", I quote.
It's an OO world.
-
Naerling wrote:
Really, was that necessary[^]?
I'm surprised your boss can read....
Sort of a cross between Lawrence of Arabia and Dilbert.[^]
-Or-
A Dead ringer for Kate Winslett[^]Have I given such a bad impression of him? :laugh:
It's an OO world.
-
Naerling wrote:
I prefer seperate technical documents
The 1970's called, they want their developer back ;-) If people rarely keep comments in sync with the code, the chance of them keeping separate technical documents is almost nil. Almost every project I've worked on with large amounts of technical documentation has been government contracts - badly run, badly designed, over budget and frequently failing, but I've not seen a single example of useful technical documentation on any project I've been lucky enough to work on. At least a comment stands some chance of being updated.
Rob Grainger wrote:
Naerling wrote:
I prefer seperate technical documents
The 1970's called, they want their developer back ;-)
If people rarely keep comments in sync with the code, the chance of them keeping separate technical documents is almost nil.This calls for JavaDoc!
Excuse me for my improper grammar and typos. It's because English is my primary language, not my first language. My first languages are C# and Java. VB, ASP, JS, PHP and SQL are my second language. Indonesian came as my third language. My fourth language? I'm still creating it, I'll let you know when it's done! :-D
-
RCoate wrote:
If you boss is from a different (programming) language background, the Select keyword could do something completely different.
I think the thing about comments here is that the Select statement is a standard .NET language construct. Therefore, you should know it if you program .NET. If you don't, you should look it up and then know it. Comments should be used for the non-obvious stuff, such as explaining (in short) an algorithm, or a couple of steps of code, or an (at first sight) unusual construct. At least, that's what I think. I'm a great proponent of commenting code though.
MicroVirus wrote:
I think the thing about comments here is that the Select statement is a standard .NET language construct. Therefore, you should know it if you program .NET. If you don't, you should look it up and then know it.
I agree with that if you are doing the programming, but if your task is to scan through the code to ensure coverage/compliance with specifications, do you have to have specific language knowledge, or do you just need to understand programming constructs and patterns? I haven't had this specific issue, but I have done debugging sessions with programmers who have no background in .Net. Semantic comments can be very helpful. Not trying to suggest that things should be overcommented. I am a big believer in inteligent method and property naming so that code is largly self commenting, but I do understand what could drive that sort of comment request.
-
Clearly, you should have given him a more useful comment, such as...
' Reroutes the neutrino flow through the primary EPS conduits.
frm.SelectProud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels) -
Nah, he just "wants to see green", I quote.
It's an OO world.
-
Last week I wrote a small library that would either startup a Form or focus an already open one, based on the Form you wanted to start. My boss wanted me to make a prototype that he could approve (approval can be reached by not using to much interfaces... He doesn't like them because it will make code harder to read and debug). So I was done writing it and showed him what I had made. First thing he said was that I didn't have comments in my code (well duh, he told me to finish it asap and he wanted to approve it first). So I had to put a comment above the Function FormCanBeShown that returns a Boolean. Yeah, what possibly could it do? Even better, I had the code
frm.Select
Boss: "What does this do?" Me: "It selects the Form... Basic Microsoft functionality..." *Hoovers over it to get MS IntelliSense prove of what I just said* Boss: "Well, I wouldn't know that, put some commentary there." And then the code looked like this:
' Activates the Control.
frm.SelectReally, was that necessary[^]?
It's an OO world.
there should be minimum comments in the code, as they are not maintained properly and often lead to confusions. comments should be put unless some very convoluted things are going on
No matter how fast light travels, it finds the darkness has always got there first, and is waiting for it
-
there should be minimum comments in the code, as they are not maintained properly and often lead to confusions. comments should be put unless some very convoluted things are going on
No matter how fast light travels, it finds the darkness has always got there first, and is waiting for it
-
We have programmed with .NET WinForms for 7 years now, my boss too (and probably more than any of us). Documenting methods that are already documented just seems like such a waste of space. Our code is full of such obvious comments...
' Set the caption of the label.
Label1.Test = "Saved successfully"' Saves the Product.
customer.SaveDo you see the problem? Everyone can see that the TEXT of a label is set, even though comments say caption (all throughout the software, copy/paste mentality). Even worse for the product/customer. People copy and edit code, they don't edit comments. If I had to comment each and every .NET Framework method like that the development time gets quite a bit longer... I have learned to not read comments, because they do not currently add any value to our code, just clutter. Every comment needs to be maintained, just like any other piece of code. For some reason it never happens. And everytime my boss asks me to comment the obvious once again I die a little inside. I'm not sure what is worse, uncommented code or overcommented code. At least uncommented code says what it does (right there in the code), if comments do the same is always a question.
It's an OO world.
Terrible comments. The first "Set the caption of the label." What does the label pertain to? Better yet, change the name of the label to "lblSaveStatus" or something like that. GREAT code is mostly self-documenting. The second comment looks just plain wrong. From the code, it looks like you are saving a "Customer", but the comment says "Saves the Product." The comment is inconsistant with the code.
-
Terrible comments. The first "Set the caption of the label." What does the label pertain to? Better yet, change the name of the label to "lblSaveStatus" or something like that. GREAT code is mostly self-documenting. The second comment looks just plain wrong. From the code, it looks like you are saving a "Customer", but the comment says "Saves the Product." The comment is inconsistant with the code.
tobep wrote:
GREAT code is mostly self-documenting.
My boss just doesn't want it... Nothing beats commenting the hell out of your code :(
It's an OO world.
public class Naerling : Lazy<Person>{}
-
Naerling wrote:
I prefer seperate technical documents
The 1970's called, they want their developer back ;-) If people rarely keep comments in sync with the code, the chance of them keeping separate technical documents is almost nil. Almost every project I've worked on with large amounts of technical documentation has been government contracts - badly run, badly designed, over budget and frequently failing, but I've not seen a single example of useful technical documentation on any project I've been lucky enough to work on. At least a comment stands some chance of being updated.
Rob Grainger wrote:
The 1970's called, they want their developer back ;-)
If people rarely keep comments in sync with the code, the chance of them keeping separate technical documents is almost nil.Actually that is exactly what our company did in the 80s to get ISO certification. Our entire software development process was defined around keeping everything in sync. And it worked!
Rob Grainger wrote:
Almost every project I've worked on with large amounts of technical documentation has been government contracts - badly run, badly designed, over budget and frequently failing, but I've not seen a single example of useful technical documentation on any project I've been lucky enough to work on.
Funny you are saying this, because before we introduced extensive documentation and the process around it, we did have issues with budget and time overruns, but rarely after. I've learned - by example - that a well organized process put into action by a disciplined team can produce incredibly high quality output with predictable results. And the documentation was crucial to that! Before we had that extensive documentation, we lost too much time reimplementing stuff that wasn't specified in sufficient detail. Of course, back then the process we had was a modified waterfall model. Nowadays, with agile development, you need a lot less documentation - it's bound to change anyways. In the end, what it all comes down to is that you need a good process. if that process requires a lot of documentation, then you need that. If the process can do without, then you don't. OTOH, if the process is bad, then no amount of documentation can save you.
