October 5, 2015 at 11:58 am
if 1 = 0
begin
--add auditing table entry
insert into audit_log(time, user, p)
select getdate(), @@user_name, @PARAMETER;
--IN FIX:5433 2014-01-02, removing audit detail logging
--declare @audit_id int;
--select @audit_id = scope_identity();
--insert into audit_detail(log_id, type)
--select @audit_id, 123;
end
:crazy: Why would anyone ever do this instead of just commenting the code out?
October 5, 2015 at 12:23 pm
Pretty hard to figure out what datetime, username and a id from a table unknown unless that's the only audit they ever did in which case the name of the audit table should indicate what id is going to be in there.
I have to believe that this was written strictly for example and not as some real thing the author pulled from a project.
October 5, 2015 at 1:11 pm
billp 37934 (10/5/2015)
I'm with Jeff on the header saying what the SQL is supposed to do. When debugging if a header says what it's supposed to do and the code does something else I know the mistake is in the code. If the header says what it's supposed to do and it does that then I know we have a design error and I have to broaden my thinking. It's very helpful in cases where the code is complex
Totally agree. Give a nice simple comment to point me in the right direction as to what the code is about.
October 5, 2015 at 3:34 pm
sknox (10/5/2015)
if 1 = 0
begin
--add auditing table entry
insert into audit_log(time, user, p)
select getdate(), @@user_name, @PARAMETER;
--IN FIX:5433 2014-01-02, removing audit detail logging
--declare @audit_id int;
--select @audit_id = scope_identity();
--insert into audit_detail(log_id, type)
--select @audit_id, 123;
end
:crazy: Why would anyone ever do this instead of just commenting the code out?
I have no idea why people don't comment or delete it but I see it so often in t-sql and app code, odd but true "if (1 == 0) { ..." i'll never understand it 🙂
October 5, 2015 at 4:04 pm
Given the fixed width of the textboxes you have available, I would recommend editing your article to move content to the left.
October 5, 2015 at 4:10 pm
mark hutchinson (10/5/2015)
Given the fixed width of the textboxes you have available, I would recommend editing your article to move content to the left.
I guess that is another reason to write cleaner code, it fits on smaller "screens" 🙂
October 5, 2015 at 6:52 pm
not enough code review and coaching?
It's amazing how easy it is to make a living as a programmer for years writing the stupidest code. It's a shame though. I've always thought if all programmers were as good as the top say 25% (an arguable number) we have today then we'd only need a fraction of them and the bottom 50% probably couldn't find a job. It seems that so much of what's done is to redo stuff that other people have done ridiculously badly. I guess the only other thing is all the stuff that's redone, not because it's bad, but because it is not the way the new guy would have done it.
Bah, humbug
October 5, 2015 at 7:37 pm
billp 37934 (10/5/2015)
not enough code review and coaching?It's amazing how easy it is to make a living as a programmer for years writing the stupidest code. It's a shame though. I've always thought if all programmers were as good as the top say 25% (an arguable number) we have today then we'd only need a fraction of them and the bottom 50% probably couldn't find a job. It seems that so much of what's done is to redo stuff that other people have done ridiculously badly. I guess the only other thing is all the stuff that's redone, not because it's bad, but because it is not the way the new guy would have done it.
Bah, humbug
Yes, but one of the best ways to become a good programmer is to learn what not to do from a bad programmer. Often this is yourself -- go back and look at code you wrote ten years ago. If you don't find several bad practices that you'd never do today, you probably haven't learned enough in the last ten years.
October 5, 2015 at 7:56 pm
I can't argue with you there. I think even better learning in my career has come from posting code on boards like this and having my peer's tear into it. It's also the hardest thing to do. Actually other than SQL I haven't coded for awhile. But I have found that people who post to boards and get peer reviewed are typically not the programmers who write silly things like
if 1==0
or if x==1 then <do>
elseif y==2 then <do>
elseif z==3 then <do>
etc. to unbelievable levels of depth when a case statement will do.
Anyway this is a big digression from the original article.
My summary is I don't think making the code as small as possible makes it clear. Making it clear means making it as obvious as possible what it is intended to do and then actually what it does. Personally I think parameter lists in the comment header are good if you put what the parameters are supposed to be unless it's painfully obvious from the name. empId hardly needs explanation but many things do. Depending on going to other places as your most important way of getting the information you need to understand code is not, in my opinion, writing cleaner code. That doesn't mean I don't believe in using source control and check in comments, I do. In fact I think you should check in small chunks so your checkin comments can be clear and succinct about what's been done to the code. But the reasoning that comments get out of sync because programmers don't think about them so SC is better is like saying, coders will always comment source control better than comments. I just don't think that's true.
October 5, 2015 at 8:19 pm
You should read The DailyWTF every day. It is an excellent source of what-not-to-do.
October 6, 2015 at 12:33 am
could version control be used to keep hints to project documentation? I am trying to imagine such a scenario when the coders rezolve the bugs & change requests, the daily activities..., and from time to time we get a picture to how the project grew.
what vcs integrates with server management console ?
November 16, 2016 at 5:18 am
As a coworker notes, application software typically outlives things like version control systems. Relying on VCS to house documentation presents a problem when the old VCS data cannot be ported to the new VCS software.
And while a set of unit tests can exist that demonstrates every possible usage of the code, that is not likely the place a support person will look at 2:30 am when trying to determine why the stored procedure does not work properly. When you are responding to a down system you need to know what is going on now, not after spending a few hours wading through unit tests and VCS check-in comments.
------------
Buy the ticket, take the ride. -- Hunter S. Thompson
Viewing 12 posts - 16 through 26 (of 26 total)
You must be logged in to reply to this topic. Login to reply