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.
-
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 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, 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.
While code should have the goal of being self commenting, there are times I find that some comments are appropriate. For instance, in functions where complex computations are involved, I'll often add comments so that in X years from now, after I've totally forgotten what I did, I don't have to spend an appreciable amount of time coming back up to speed...Or maybe it's that I came from an assembler background :rolleyes: .
-
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:
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)
-
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.
Sounds like the rules were made by a zealot who doesn't have to write or read code himself/herself.
-
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, 2001At 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.
-
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
