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.
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]
-
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.
Point them to the other extreme: Literate Programming.[^]
-
Point them to the other extreme: Literate Programming.[^]
Yes, I have a book which details a project in literate programming. I find it a bit confusing...
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.
Rob Philpott wrote:
comments in code are not allowed
That's just plain silly. :sigh: /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
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"
// 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 :)
-
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 good to me :) (probably just because that is what I do)
xacc.ide
IronScheme - 1.0 RC 1 - out now!
((λ (x) `(,x ',x)) '(λ (x) `(,x ',x))) The Scheme Programming Language – Fourth Edition -
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"