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.
-
John Simmons / outlaw programmer wrote:
stupidity and ignorance should be avoided at all costs.
Been a while since you were 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)
Nope, I just have a mindset about using comments.
.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 -
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.
-
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.
Ahhhhh. Dogmatic stupidity enshrined as process.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
-
Nope, I just have a mindset about using comments.
.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, 2001Yes, 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)
-
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.
Sounds fine to me, except:
Rob Philpott wrote:
). Code should be self describing, and if you need to comment something, you're better really need to consider taking it and putting in its own method with a meaningful name.
In general, with refactoring and sensible names, few methods need to be more than 10 lines long and the code does become largely self describing. Comments are needed occaisionally, especially if something difficult to understand is happening (e.g. a bit of mathematical trickery is being used) Heavy-commenting was drilled into me at university and was a difficult habit to break. It was a real epiphany for me when I went through a refactoring exercise with someone much more experienced than me, and the code came out pretty much self describing and clear.
CCC solved so far: 2 (including a Hard One!) 37!?!! - Randall, Clerks
-
I would follow their rules to the letter. No comments, at all. #regions, on the other hand...
OSDev :)
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.
-
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.
Use a gun on the moron who came up with the no comment policy.
Panic, Chaos, Destruction. My work here is done.
-
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.
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)
-
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.
Comments should be allowed for special situation like when it's not clear why a process order is required to work around an issue. Having worked in Share Point alot this year, there are workarounds I had to do that w/o comments would make future programmers looking at the code go wtf.
-
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.
Well we do agile (been doing 'agile' for years and years and years) but anyone that didn't take a coupe of seconds to comment what they are up to would be hung, drawn and eighthed by everyone else. Utter arrogance to believe that your code is self describing to anyone else 3 months or so from now however simple you believe it to be.
-
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 second that, at best they hide code, at worst (and I have seen this) they surround stuff that should be encapsulated in a new class type.
Rob Philpott wrote:
First thing I always do is CTRL+M+P to expand them away, you know so I can see the code.
And then delete them.
CCC solved so far: 2 (including a Hard One!) 37!?!! - Randall, Clerks
-
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 whole " no comment" thing sounds like someone(s) trying to save their jobs. Think we had a posting on that the other day. I'm on the mind frame any comments are better then no comments at all. Personally I use comments as "bookmarks" of sorts. That way after an hour of lunch or time after work, once I come back it's not " what was I doing again?" type of deal. Even if comments get... sloppy, least there is a path. Now if say there was planning and design before hand of whats to be done, than fine. The planning becomes a form of commenting. There is a way to be "agile" and efficient with out killing off the quality. it's finding that happy medium. edit; found the article " how to write unmaintainable code and keep your job for life." :D I love that article :)
///////////////// Groucho Marx Those are my principals, if you don't like them… I have others.
modified on Wednesday, December 23, 2009 11:27 AM
-
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.
Is there any limitation on method names?
public class SambaWatcher_ThisClassWrapsAnOlderWin32ApiToMonitorFileChangesOnASambaShareThatDoesntSupportTheModernApiCalledByFileChangeNotification
Without an explanation of why the "proper" way to do this won't work there's nothing to keep an agidiot from helpfully refactoring the redundant class out of existence. :rolleyes:
3x12=36 2x12=24 1x12=12 0x12=18
-
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:
One rule the team has is that comments in code are not allowed (no, really).
Give the man some post-it notes as a present for Christmas :) It wouldn't be a bad idea to keep documentation on all living code. Comments make an application easier to maintain. Not every design decision can be expressed in the form of code - was it implemented in a way to be backward compatible to an ancient format? Is it an obscure form of optimization? Was that method implemented using an inefficient search-algorithm for a technical issue, or just out of time-pressure? The most beautiful piece of code that I ever came across was commented as if the reader was going through a book, turning the code itself into a huge textbook. That would pose the 'other' extreme. There's a sweet spot, somewhere between those two extremes.
I are Troll :suss:
-
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.
1. Code for human consumption 2. Comment often and comment well Self describing code only describes what the code does not what was intended so there is no way of telling when the code is doing something it was not intended to do. What you are doing is not "Agile" - it is "Fragile"
'--8<------------------------ Ex Datis: Duncan Jones Merrion Computing Ltd
-
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.
Generally speaking, good code does not need comments. I would probably not want that to be a rule, but I understand why they did it. Especially for .net code.
I didn't get any requirements for the signature
-
1. Code for human consumption 2. Comment often and comment well Self describing code only describes what the code does not what was intended so there is no way of telling when the code is doing something it was not intended to do. What you are doing is not "Agile" - it is "Fragile"
'--8<------------------------ Ex Datis: Duncan Jones Merrion Computing Ltd
Absolutely RIGHT!!! Fragile is spot on.
-
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 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. 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) 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: 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. 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.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
-
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.
It's interesting how this 'battle' has been going on now for quite some time as most languages support some form of commenting. It suggests to me that comments are like most other language constructs. That is they are necessary sometimes, but not always required. For me, as long as the code is reviewed and deemed as correct and maintainable, then whether it has comments or flashing lights, doesn't seem too important. :)
Chris Meech I am Canadian. [heard in a local bar] In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]