No comment
-
Where I work presently, we are 'agile' if you will. Very disciplined agile. One rule the team has is that comments in code are not allowed (no, really). Code should be self describing, and if you need to comment something, you're better taking it and putting in its own method with a meaningful name. I'd be interested to hear what people's opionions on this are.
Regards, Rob Philpott.
I am uncomfortable of doing things without any reason. In the past like I was being told to have a specific style of commenting for generating some documents from code, and we are only 4 people in dev team at same location, who needs style for this. Micromanagement of coding habits by an non-programmer is always harmful to programmer. that's what I think.
-
Where I work presently, we are 'agile' if you will. Very disciplined agile. One rule the team has is that comments in code are not allowed (no, really). Code should be self describing, and if you need to comment something, you're better taking it and putting in its own method with a meaningful name. I'd be interested to hear what people's opionions on this are.
Regards, Rob Philpott.
Makes perfect sense to me, given that the agile methodology is all about being nimble enough to avoid accountability. :)
Christopher Duncan www.PracticalUSA.com Author of The Career Programmer and Unite the Tribes Copywriting Services
-
Yes, comments are good... But do you really think you can avoid stupidity and ignorance in the business world?
Proud to have finally moved to the A-Ark. Which one are you in? Author of Guardians of Xen (Sci-Fi/Fantasy novel)
The business world is absolutely dependent on stupidity and ignorance (hopefully your competitors and customers, but hey, whatever works).
-
Where I work presently, we are 'agile' if you will. Very disciplined agile. One rule the team has is that comments in code are not allowed (no, really). Code should be self describing, and if you need to comment something, you're better taking it and putting in its own method with a meaningful name. I'd be interested to hear what people's opionions on this are.
Regards, Rob Philpott.
Rob Philpott wrote:
I'd be interested to hear what people's opionions on this are.
How the f*** do you document a complicated algorithm or architecture? There's a lot of information lost when coding, the first thing is the decisions made that lead up to the current implementation. And what better place to put most of that but in code comments??? Idiots. Marc
I'm not overthinking the problem, I just felt like I needed a small, unimportant, uninteresting rant! - Martin Hart Turner
-
I am uncomfortable of doing things without any reason. In the past like I was being told to have a specific style of commenting for generating some documents from code, and we are only 4 people in dev team at same location, who needs style for this. Micromanagement of coding habits by an non-programmer is always harmful to programmer. that's what I think.
Abhi Lahare wrote:
Micromanagement of coding habits by an non-programmer is always harmful to programmer.
FTFY
-
I don't think they're allowed either, which is fine by me as I HATE them. First thing I always do is CTRL+M+P to expand them away, you know so I can see the code.
Regards, Rob Philpott.
-
Abhi Lahare wrote:
Micromanagement of coding habits by an non-programmer is always harmful to programmer.
FTFY
-
// introduce the point with a mixture of metaphor and // colloquialism, seeking to avoid the pedantic. I would be very agile if I were you - agile enough to get out of the way of the train wreck about to happen. Undocumented code is unmaintainable code, and it will someday return to bite you in the arse. // cite example One of my first assignments in the post-college working world was to port old applications from obsolete minicomputers to new ones. Constructs like DATA 1,123.4521,42Q,.003241563, -.01000342701, .0000128546 READ A, B, C CALL 201(A,B,C READ X, Y, Z I= 9.8 + X J= 9.8 + Y K= 9.8 + Z CALL 142(I,J,K) // supporting the point with a segue into relevant anecdote were all too common. In fact, something very like this led me to my first professional faux pas. I bitched about the awful code to my department head at great length, describing in detail the obvious deficiencies of the idiot who wrote the original program, including the likelihood that he met only one of his parents, if that many. He read the printout, agreed with me, hung his head low and admitted that he'd written it ten years before. :doh: // recognize and rebut the alternate view I realize that modern languages are much more readable, and OOP techniques, structured programming, et al result in better organization, but one can't safely assume that the poor sap who one day might be expected to use or modify today's code will be familiar with the language or the framework on which it is based. Such an assumption is folly, and an invitation to failure. // and suggest alternate routes for those in disagreement. Well constructed comments that clearly describe the programmer's intent and assumptions are part of the product; neglecting them is sufficient cause for giving the programmer an opportunity to seek a new career path.
FTFY :)
Thanks, Tim! :-D It's much more readable now. ;)
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
-
Yes, comments are good... But do you really think you can avoid stupidity and ignorance in the business world?
Proud to have finally moved to the A-Ark. Which one are you in? Author of Guardians of Xen (Sci-Fi/Fantasy novel)
Ian Shlasko wrote:
But do you really think you can avoid stupidity and ignorance in the business world?
That question is outside the scope of the original message. We're talking about development practices, not business models.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001 -
Geeky Proof that Agile is Bad, from a former Warcraft Addict: * The "Agile" process is all about... Wait for it... Agility! * Agility is a stat favored by rogues and hunters. * Therefore, "Agile" development is for woodsmen and brigands, which shouldn't be allowed anywhere near code.
Proud to have finally moved to the A-Ark. Which one are you in? Author of Guardians of Xen (Sci-Fi/Fantasy novel)
The reason it has to be "Agile" is that it can't take a hit.
-
Where I work presently, we are 'agile' if you will. Very disciplined agile. One rule the team has is that comments in code are not allowed (no, really). Code should be self describing, and if you need to comment something, you're better taking it and putting in its own method with a meaningful name. I'd be interested to hear what people's opionions on this are.
Regards, Rob Philpott.
The Agile Manifesto does not say "Thou shalt do no commenting". If you write code using descriptive naming and short methods, there should be less need to comment but there will always be situations where a comment may be appropriate.
-
Yes, comments are good... But do you really think you can avoid stupidity and ignorance in the business world?
Proud to have finally moved to the A-Ark. Which one are you in? Author of Guardians of Xen (Sci-Fi/Fantasy novel)
Ian Shlasko wrote:
Yes, comments are good... But do you really think you can avoid stupidity and ignorance in the business world?
Assuming so much stupidity around, then... can you avoid stupid comments? :) In this case, comments are definitely not needed...
You can't turn lead into gold, unless you've built yourself a nuclear plant.
-
Ian Shlasko wrote:
But do you really think you can avoid stupidity and ignorance in the business world?
That question is outside the scope of the original message. We're talking about development practices, not business models.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001John Simmons / outlaw programmer wrote:
That question is outside the scope of the original message. We're talking about development practices, not business models
Nevermind... If stupidity were a resource, it would be the most universal and evenly spread resource... :)
You can't turn lead into gold, unless you've built yourself a nuclear plant.
-
At a previous job a consultant mentioned and then explained what agile was and then he declared that's what we'd been doing all along. He missed the part about defining what you're doing and then not changing that until sometime later as another cycle. Agile, as I've seen it, mostly keeps documentation of the system from happening and foresight of the product or system from taking place. When customers ask for documentation we didn't have much to say other than to sputter and then commit to making some later. It was never part of the project. Poorly written comments are just as bad as no comments. What the code is doing doesn't necessarily explain the why. Just my opinion though.
wolfbinary wrote:
Poorly written comments are just as bad as no comments. What the code is doing doesn't necessarily explain the why. Just my opinion though
Absolutely, and it also depends on the language used. Writing assembly language without comments is just nonsense. On the other hand, in a language like C#, it makes a lot of sense to spend a bit of time writing self explanatory code. Refactoring can help too keeping the code understandable. Writing comments has become one of many ways to help coping with code evolution.
You can't turn lead into gold, unless you've built yourself a nuclear plant.
-
Where I work presently, we are 'agile' if you will. Very disciplined agile. One rule the team has is that comments in code are not allowed (no, really). Code should be self describing, and if you need to comment something, you're better taking it and putting in its own method with a meaningful name. I'd be interested to hear what people's opionions on this are.
Regards, Rob Philpott.
That's just so much bollocks I don't believe anyone would be willing to put the rule in writing! Code should be self-describing - sure upto a point. BUt it becoimes illegible if you start having method names that are entire descriptions of themselves
CustomerListIncludingBasicDetailsFordisplayingInAGridOrSimilarGui GetCustomerListIncludingDisabledCustomersWithExistingOrdersButExcludingCustomersWithZeroDebt();
is just somehow not readable! Sure its an exaggeration. IMHO you should START every method by writing the comments (this is akin to TDD). Comment th method, describing what its purpose is, that is ALL a developer should need to look at again UNLESS the method needs to be refactored due to errors or changes in requirements. You SHOULD be able to read a program merely by reading the comments. Why don't people code like this in the real world? Because their lazy, good for nothing, spotty pizza eating nerds, that's why! Oh, and hey also realise that comments often do not get maintained with the code, and so become out of date, and so become useless. So - let's fix the problem by not commenting, so making it go away. With agile you are surely doing code reiews? Well, these should include the comments (in fact they souldSTART with the comments - the code merely reflects the descriptiuno which is based on the specification. And also (Ohhhh you got my gander up!) I'd be interested in seeing in this rule book whatg the justifiation for that rule actually is? Or is it just "thou shalt not..." IMHO any coding rule, guideling, practice, expectation or standard MUST have a justification and MUST be fluid over time. "Do not use Comments - because I don't like them" doesn't cut it.
___________________________________________ .\\axxx (That's an 'M')
-
That's just so much bollocks I don't believe anyone would be willing to put the rule in writing! Code should be self-describing - sure upto a point. BUt it becoimes illegible if you start having method names that are entire descriptions of themselves
CustomerListIncludingBasicDetailsFordisplayingInAGridOrSimilarGui GetCustomerListIncludingDisabledCustomersWithExistingOrdersButExcludingCustomersWithZeroDebt();
is just somehow not readable! Sure its an exaggeration. IMHO you should START every method by writing the comments (this is akin to TDD). Comment th method, describing what its purpose is, that is ALL a developer should need to look at again UNLESS the method needs to be refactored due to errors or changes in requirements. You SHOULD be able to read a program merely by reading the comments. Why don't people code like this in the real world? Because their lazy, good for nothing, spotty pizza eating nerds, that's why! Oh, and hey also realise that comments often do not get maintained with the code, and so become out of date, and so become useless. So - let's fix the problem by not commenting, so making it go away. With agile you are surely doing code reiews? Well, these should include the comments (in fact they souldSTART with the comments - the code merely reflects the descriptiuno which is based on the specification. And also (Ohhhh you got my gander up!) I'd be interested in seeing in this rule book whatg the justifiation for that rule actually is? Or is it just "thou shalt not..." IMHO any coding rule, guideling, practice, expectation or standard MUST have a justification and MUST be fluid over time. "Do not use Comments - because I don't like them" doesn't cut it.
___________________________________________ .\\axxx (That's an 'M')
_Maxxx_ wrote:
You SHOULD be able to read a program merely by reading the comments.
Completely agree! In fact, if the code is complicated enough, I start out with comments to give myself a list of things to do. I start with the high level comment then I make more specific comments as I write code. If the code is pretty routine, I'll usually write a bunch of it then come back later to comment it (for the benefit of the next person who will work on it). Makes it easier to break code into logical chunks, which can be more readily understood. I don't see why others see comments as a problem.
-
I would be quite verbal in my protestations regarding the "no comments allowed" policy. Agile is fine (I guess), but stupidity and ignorance should be avoided at all costs.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001John Simmons / outlaw programmer wrote:
I would be quite verbal in my protestations regarding the "no comments allowed" policy. Agile is fine (I guess), but stupidity and ignorance should be avoided at all costs.
I was going to reply to the OP, but you said exactly what I wanted to say.
I wanna be a eunuchs developer! Pass me a bread knife!
-
I don't think they're allowed either, which is fine by me as I HATE them. First thing I always do is CTRL+M+P to expand them away, you know so I can see the code.
Regards, Rob Philpott.
I disagree. Regions are useful if used sparingly and appropriately.
do or do not, there is no try
-
Where I work presently, we are 'agile' if you will. Very disciplined agile. One rule the team has is that comments in code are not allowed (no, really). Code should be self describing, and if you need to comment something, you're better taking it and putting in its own method with a meaningful name. I'd be interested to hear what people's opionions on this are.
Regards, Rob Philpott.
Meaningful method names are all very well and good but don't often help with how the method is implemented, and sometimes if you were to fully describe a method in its name it would be impossible to read! For instance I've just finished writing a method which takes a hex value as a string (because that's how its supplied) and converts it to a single precision value. Now naming the method appropriately is fine and breaking it apart is okay as well but sometimes you just really need to explain why you're doing something so that people who are unfamiliar with the code can easily understand what is going on. I agree that bad comments are as good as no comments at all but I think that code should be commented. To not do so is the same as loading a gun, aiming it square at your foot and pulling the trigger.
-
Where I work presently, we are 'agile' if you will. Very disciplined agile. One rule the team has is that comments in code are not allowed (no, really). Code should be self describing, and if you need to comment something, you're better taking it and putting in its own method with a meaningful name. I'd be interested to hear what people's opionions on this are.
Regards, Rob Philpott.