Cut out for Greenpeace...
-
So my boss is like a rabbit. He just loves his greens. Unclear naming should stay unclear by commenting it (helper was never used, but that's beside the point).
' A helper variable.
Dim helper As BooleanOf course we could make clear comments in favor of properly naming our variables.
' s is a SalesOrder
s.DoSomething()p.DoSomethingElse ' PurchaseOrder
The obvious also needs extra explanation.
i = nX + nY ' Add nX and nY
In case we ever want to compile our code into a beginners how-to-program book.
' Assign the value to the variable
i = 10We just can't have enough comments!
' Refresh the screen
RefreshScreenKeep an active log inside your code, you never know when you need it (SVN alone isn't good enough)... (date, initials, ticket number). The fun thing about this is that when a fix is larger than a few code files it does not have to be commented. If it is only a few code files chances are this piece of commentary is copied to each of them, sometimes in multiple places in the same file.
' 2012-09-22 N Ticket # 666.
' The client wants this fix because... Bla, bla, bla...
CallSomeMethodSome of this guys methods are commented line by line with these kinds of comments... :wtf: I tried to talk to him about it, but he's convinced code is unreadable and can never be understood easily by just reading it. Comments are absolutely necessary if you, or another programmer, ever want to quickly make changes to the code. This is the same guy who thinks making a seperate class for almost every method (and randomly make it non-shared/non-static or shared/static) makes code more clear and readable (and single responsibility principle is a bonus!) and who just doesn't use access modifiers out of laziness or indifference... Of course he is my boss and has eight years of experience where I have only two (how often I had to hear that) so when I disagree with him I'm rude and inexperienced. I guess someday I'll laugh about it :~
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
} -
So my boss is like a rabbit. He just loves his greens. Unclear naming should stay unclear by commenting it (helper was never used, but that's beside the point).
' A helper variable.
Dim helper As BooleanOf course we could make clear comments in favor of properly naming our variables.
' s is a SalesOrder
s.DoSomething()p.DoSomethingElse ' PurchaseOrder
The obvious also needs extra explanation.
i = nX + nY ' Add nX and nY
In case we ever want to compile our code into a beginners how-to-program book.
' Assign the value to the variable
i = 10We just can't have enough comments!
' Refresh the screen
RefreshScreenKeep an active log inside your code, you never know when you need it (SVN alone isn't good enough)... (date, initials, ticket number). The fun thing about this is that when a fix is larger than a few code files it does not have to be commented. If it is only a few code files chances are this piece of commentary is copied to each of them, sometimes in multiple places in the same file.
' 2012-09-22 N Ticket # 666.
' The client wants this fix because... Bla, bla, bla...
CallSomeMethodSome of this guys methods are commented line by line with these kinds of comments... :wtf: I tried to talk to him about it, but he's convinced code is unreadable and can never be understood easily by just reading it. Comments are absolutely necessary if you, or another programmer, ever want to quickly make changes to the code. This is the same guy who thinks making a seperate class for almost every method (and randomly make it non-shared/non-static or shared/static) makes code more clear and readable (and single responsibility principle is a bonus!) and who just doesn't use access modifiers out of laziness or indifference... Of course he is my boss and has eight years of experience where I have only two (how often I had to hear that) so when I disagree with him I'm rude and inexperienced. I guess someday I'll laugh about it :~
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}Naerling wrote:
Keep an active log inside your code
Ugh. I hate that. At my last job, they were all about that. Half a million lines of SQL, and none of it in version control (it was all nearly lost once, except I and another person had a personal backup).
Naerling wrote:
I guess someday I'll laugh about it
When the company collapses and you find a new job with reasonable code practices.
-
Naerling wrote:
Keep an active log inside your code
Ugh. I hate that. At my last job, they were all about that. Half a million lines of SQL, and none of it in version control (it was all nearly lost once, except I and another person had a personal backup).
Naerling wrote:
I guess someday I'll laugh about it
When the company collapses and you find a new job with reasonable code practices.
AspDotNetDev wrote:
When the company collapses and you find a new job with reasonable code practices.
Nah, they've been good to me and though I disagree with their code practices (and I disagree on almost everything with the guy who writes these comments) I don't want them to collapse... The funny thing is that the guy who writes these comments taught me to code! Luckily I surpassed my 'master' in every way (after about a year) :) Although he's still the better SQL Server guy.
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
} -
So my boss is like a rabbit. He just loves his greens. Unclear naming should stay unclear by commenting it (helper was never used, but that's beside the point).
' A helper variable.
Dim helper As BooleanOf course we could make clear comments in favor of properly naming our variables.
' s is a SalesOrder
s.DoSomething()p.DoSomethingElse ' PurchaseOrder
The obvious also needs extra explanation.
i = nX + nY ' Add nX and nY
In case we ever want to compile our code into a beginners how-to-program book.
' Assign the value to the variable
i = 10We just can't have enough comments!
' Refresh the screen
RefreshScreenKeep an active log inside your code, you never know when you need it (SVN alone isn't good enough)... (date, initials, ticket number). The fun thing about this is that when a fix is larger than a few code files it does not have to be commented. If it is only a few code files chances are this piece of commentary is copied to each of them, sometimes in multiple places in the same file.
' 2012-09-22 N Ticket # 666.
' The client wants this fix because... Bla, bla, bla...
CallSomeMethodSome of this guys methods are commented line by line with these kinds of comments... :wtf: I tried to talk to him about it, but he's convinced code is unreadable and can never be understood easily by just reading it. Comments are absolutely necessary if you, or another programmer, ever want to quickly make changes to the code. This is the same guy who thinks making a seperate class for almost every method (and randomly make it non-shared/non-static or shared/static) makes code more clear and readable (and single responsibility principle is a bonus!) and who just doesn't use access modifiers out of laziness or indifference... Of course he is my boss and has eight years of experience where I have only two (how often I had to hear that) so when I disagree with him I'm rude and inexperienced. I guess someday I'll laugh about it :~
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}(Really) Bad smell, think we should refactor!
-
Naerling wrote:
Keep an active log inside your code
Ugh. I hate that. At my last job, they were all about that. Half a million lines of SQL, and none of it in version control (it was all nearly lost once, except I and another person had a personal backup).
Naerling wrote:
I guess someday I'll laugh about it
When the company collapses and you find a new job with reasonable code practices.
-
So my boss is like a rabbit. He just loves his greens. Unclear naming should stay unclear by commenting it (helper was never used, but that's beside the point).
' A helper variable.
Dim helper As BooleanOf course we could make clear comments in favor of properly naming our variables.
' s is a SalesOrder
s.DoSomething()p.DoSomethingElse ' PurchaseOrder
The obvious also needs extra explanation.
i = nX + nY ' Add nX and nY
In case we ever want to compile our code into a beginners how-to-program book.
' Assign the value to the variable
i = 10We just can't have enough comments!
' Refresh the screen
RefreshScreenKeep an active log inside your code, you never know when you need it (SVN alone isn't good enough)... (date, initials, ticket number). The fun thing about this is that when a fix is larger than a few code files it does not have to be commented. If it is only a few code files chances are this piece of commentary is copied to each of them, sometimes in multiple places in the same file.
' 2012-09-22 N Ticket # 666.
' The client wants this fix because... Bla, bla, bla...
CallSomeMethodSome of this guys methods are commented line by line with these kinds of comments... :wtf: I tried to talk to him about it, but he's convinced code is unreadable and can never be understood easily by just reading it. Comments are absolutely necessary if you, or another programmer, ever want to quickly make changes to the code. This is the same guy who thinks making a seperate class for almost every method (and randomly make it non-shared/non-static or shared/static) makes code more clear and readable (and single responsibility principle is a bonus!) and who just doesn't use access modifiers out of laziness or indifference... Of course he is my boss and has eight years of experience where I have only two (how often I had to hear that) so when I disagree with him I'm rude and inexperienced. I guess someday I'll laugh about it :~
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}I like to comment my code, but only where really necessary. I also use meaningful variable names and method names so that the code is largely self-commenting. It is rare to see someone who wants both pointless comments and meaningless names, fortunately. ;) If those things are wrong there are likely other bad practices and I would think about looking for a better place to work.
Just because the code works, it doesn't mean that it is good code.
-
I like to comment my code, but only where really necessary. I also use meaningful variable names and method names so that the code is largely self-commenting. It is rare to see someone who wants both pointless comments and meaningless names, fortunately. ;) If those things are wrong there are likely other bad practices and I would think about looking for a better place to work.
Just because the code works, it doesn't mean that it is good code.
CIDev wrote:
there are likely other bad practices
I found the same piece of code something like five times (EXACTLY the same). And then other pieces of code five times too. I found slightly different code even more often (don't make a function with input parameters, copy paste the code and change a word or two). I found functions that were called ChangeX(ByVal x As Integer) that also changes Y and Z, ChangeY(ByVal y As Integer) that also changes X and Z etc. Worst part is, this guy coded them and still called ChangeX, ChangeY and ChangeZ one after the other. Worst has still to come... This guy is technical director and pretends to be quality insurer (he is, but doesn't really insure anything). He has told me I should not code MessageBox.Show("Hello"), I should've done: Dim prompt As String = "Hello" MessageBox.Show(prompt) because... I don't know... He really doesn't understand I guess! If he would've coded it he wouldn't even have typed 'As String' because that's only inconvenient. I've even seen him use switch statements for booleans! Somehow this guy doesn't like If statements... And this guy is 'by the book' (really, if he sees something he doesn't like he always has a book that defends his position, it's freaky!)...
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
} -
CIDev wrote:
there are likely other bad practices
I found the same piece of code something like five times (EXACTLY the same). And then other pieces of code five times too. I found slightly different code even more often (don't make a function with input parameters, copy paste the code and change a word or two). I found functions that were called ChangeX(ByVal x As Integer) that also changes Y and Z, ChangeY(ByVal y As Integer) that also changes X and Z etc. Worst part is, this guy coded them and still called ChangeX, ChangeY and ChangeZ one after the other. Worst has still to come... This guy is technical director and pretends to be quality insurer (he is, but doesn't really insure anything). He has told me I should not code MessageBox.Show("Hello"), I should've done: Dim prompt As String = "Hello" MessageBox.Show(prompt) because... I don't know... He really doesn't understand I guess! If he would've coded it he wouldn't even have typed 'As String' because that's only inconvenient. I've even seen him use switch statements for booleans! Somehow this guy doesn't like If statements... And this guy is 'by the book' (really, if he sees something he doesn't like he always has a book that defends his position, it's freaky!)...
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}
