Coding Pet Peeves

[xcessive]

I hate people trying to reinvent the wheel.

Or using mysql_ in php.

[Chris]

Nov 20, 2010 3:08:54 GMT -8 xcessive said:

Or using mysql_ in php.

this one I need to hear and explanation for.

[xcessive]

Nov 20, 2010 10:20:23 GMT -8 Chris said:

Nov 20, 2010 3:08:54 GMT -8 xcessive said:

Or using mysql_ in php.

this one I need to hear and explanation for.

The mysql_ library of commands has been depreciated since php v3 and is no longer being actively developed, its features are also far inferior to the alternatives. Use pdo or mysqli.

www.php.net/manual/en/mysqli.overview.php
Scroll to the bottom and read.

As you can see you should be using mysqli objects, NOT mysql_

[Chris]

xcessive: Ah, fair enough. I misunderstood what you meant. I thought you mean just using a MySQL database as opposed to that.

[Bennett 🚀]

mysql_ still works though :X And is much simpler.

[xcessive]

Actually mysqli is as simple, you can use it procedurally and its basically the same as mysql_ only more powerful, faster and more secure.

Chris Phyffer, that would have been ridiculous

[Bennett 🚀]

One thing that mysqli is that _mysql isn't, is it's OO, which, for some reason, doesn't make sense in my mind.. yet.

[xcessive]

Nov 20, 2010 22:27:43 GMT -8 Bennett 🚀 said:

One thing that mysqli is that _mysql isn't, is it's OO, which, for some reason, doesn't make sense in my mind.. yet.

Like I said, it CAN BE OO, but you can use it procedurally if you like. Read the documentation

[Wormopolis]

Im guilty of so much of what all of you have lamented about in what I write that I wont even bother listing what irritates me.

[Charles Stover]

Nov 20, 2010 22:07:51 GMT -8 xcessive said:

Actually mysqli is as simple, you can use it procedurally and its basically the same as mysql_ only more powerful, faster and more secure.

Chris Phyffer, that would have been ridiculous

I still use mysql_, as I have never even so much as looked at mysqli. I have no objections to switching to it if mysql_ is deprecated (I thoroughly prefer my DirectoryIterator over readdir and what-not), but I am highly suspicious over the idea that it is faster. More powerful and more secure, maybe (although most of security resides in real escaped strings). But given that it has to work through a class, I'd suspect it's slower. Classes are always slower than functions.

[BFD]

Nov 17, 2010 15:01:04 GMT -8 Charles Stover said:

I hate brackets for one-line conditionals.

for (i=0;i<10;i++)
{
if (i%2==0)
alert("Even");
else
alert("Odd");
}

I also hate conditions when they can be inline.

for (i=0;i<10;i++)
alert(i % 2 ? "Odd" : "Even");

EDIT:
P.S. space after for and if

My peeve is that people people over-condense their code when it does not actually save a step during execution. Readibility is crucial when there is even a possibility you might need to turn code over to someone else for maintenance/enhancement. You also have to consider that often, the person maintianing code is not a proficient programmer.

Also, by expliciting marking the code to be executed with brackets (or Begin/End in a verbose language), you can prevent some difficult to identify (and even destructive bugs). Take the following T-SQL segments as an example:


IF @ysnProceed <> 0
       UPDATE tblData SET strDataField = 'CLEARED'




IF @ysnProceed <> 0
       BEGIN
    UPDATE tblData SET strDataField = 'CLEARED'
       END


If you later needed to add a delete of another table, a common mistake would be to change it as follows:


IF @ysnProceed <> 0
       UPDATE tblData SET strDataField = 'CLEARED'
       DELETE tblDataLog


This would result in a disasterous bug that will result in the second table being deleted regardless of the flag. If you always make it a habit to enclose the "then" clause in a begin/end block, it would be very difficult to make the above mistake.

Some other programming habits that annoy me, especially in code that was written by a "professional":

• Inconsistent variable names and abbreviations. It drives me nuts when I find things like numParentOrderNum and numChildOrderNo, especially when dealing with database field names. If you keep it consistent, you don't need to look things up as often.
  
• Lack of comments
  
• Obsolete code left commented out. I don't mind this when you are still debugging or developing, but once the code is deemed ready to deliver, get rid of the junk!
  
• Procedures/functions that span several hundred lines. Way back in the 90's while in college, it was drilled into our heads that you should be able to view a single function or procedure on your monitor screen without having to scroll. And that was in the days of text monitors that would only display 30 lines or so. While I think that standard is a bit impractical, I find that keeping to a single page of code per procedure is reasonable. If I notice I am approaching a full page, I usually can find areas that need to be factored out.
  
• Inconsistent indentation. You should be able to where you are in a nested if/loop/case/whatever by the indentation.
  
• Unnecessary cleverness. If you don't need to invoke an advanced language feature or complex programming technique, DON'T. If you are being paid to develope a program, you are being paid to make it work according to the specification and with a reasonable level of performance. Don't waste time trying to squeeze a few nanoseconds out of a routine that is going to be executed once or create an algorithm that while ingenious, cannot be debugged by an average programmer. The most brilliant programmer I have ever worked with was a master of making code extremely simple.
  

[xcessive]

Nov 22, 2010 19:17:41 GMT -8 Charles Stover said:

Nov 20, 2010 22:07:51 GMT -8 xcessive said:

Actually mysqli is as simple, you can use it procedurally and its basically the same as mysql_ only more powerful, faster and more secure.

Chris Phyffer, that would have been ridiculous

I still use mysql_, as I have never even so much as looked at mysqli. I have no objections to switching to it if mysql_ is deprecated (I thoroughly prefer my DirectoryIterator over readdir and what-not), but I am highly suspicious over the idea that it is faster. More powerful and more secure, maybe (although most of security resides in real escaped strings). But given that it has to work through a class, I'd suspect it's slower. Classes are always slower than functions.

As I said numerous times before, mysqli can also be used procedurally in exactly same way as mysql_, but like I inferred above its faster (procedurally) since it uses PHP 5 technology in comparison to PHP 3 technology. Also static class functions are basically the same speed as non-class bound functions. Especially considering its a scripting language.

Also mysql_ used objects to create/return some requests anyway. Read the API.

[Charles Stover]

Nov 23, 2010 11:46:33 GMT -8 BFD said:

Nov 17, 2010 15:01:04 GMT -8 Charles Stover said:

I hate brackets for one-line conditionals.

for (i=0;i<10;i++)
{
if (i%2==0)
alert("Even");
else
alert("Odd");
}

I also hate conditions when they can be inline.

for (i=0;i<10;i++)
alert(i % 2 ? "Odd" : "Even");

EDIT:
P.S. space after for and if

My peeve is that people people over-condense their code when it does not actually save a step during execution. Readibility is crucial when there is even a possibility you might need to turn code over to someone else for maintenance/enhancement. You also have to consider that often, the person maintianing code is not a proficient programmer.

Firstly, I find reading 6 lines is much harder than reading one line. Inline if statements are not hard to read once you get used to them. It also saves time during the coding process by typing much less.
Secondly, I've never been once to care about whether or not someone else on a project can read it. If someone else is working on the project, that means I'm not and that I'm not getting paid. I couldn't care less if their job is harder because my code is more efficient, both in terms of bandwidth and readability (assuming you can read inline if statements, in order to decrease script size and amount read). If they can't program on the same level as me, they shouldn't have taken my job.

Also, by expliciting marking the code to be executed with brackets (or Begin/End in a verbose language), you can prevent some difficult to identify (and even destructive bugs). Take the following T-SQL segments as an example:


IF @ysnProceed <> 0
       UPDATE tblData SET strDataField = 'CLEARED'




IF @ysnProceed <> 0
       BEGIN
    UPDATE tblData SET strDataField = 'CLEARED'
       END


If you later needed to add a delete of another table, a common mistake would be to change it as follows:


IF @ysnProceed <> 0
       UPDATE tblData SET strDataField = 'CLEARED'
       DELETE tblDataLog


This would result in a disasterous bug that will result in the second table being deleted regardless of the flag. If you always make it a habit to enclose the "then" clause in a begin/end block, it would be very difficult to make the above mistake.

If a programmer isn't familiar with the concepts of if statements, they shouldn't be writing programs of such importance. I read bracketless if statements just as sensibly as I do bracketed if statements. I dare say I would never make such a mistake and thus wouldn't need to use unnecessary brackets.
If someone is afraid of such a mistake, let them use them; but I wouldn't go so far as to say that everyone should. I think as a natural progression you should go away from using them where they are not necessary.

Some other programming habits that annoy me, especially in code that was written by a "professional":

• Inconsistent variable names and abbreviations. It drives me nuts when I find things like numParentOrderNum and numChildOrderNo, especially when dealing with database field names. If you keep it consistent, you don't need to look things up as often.
  
• Lack of comments
  
• Obsolete code left commented out. I don't mind this when you are still debugging or developing, but once the code is deemed ready to deliver, get rid of the junk!
  
• Procedures/functions that span several hundred lines. Way back in the 90's while in college, it was drilled into our heads that you should be able to view a single function or procedure on your monitor screen without having to scroll. And that was in the days of text monitors that would only display 30 lines or so. While I think that standard is a bit impractical, I find that keeping to a single page of code per procedure is reasonable. If I notice I am approaching a full page, I usually can find areas that need to be factored out.
  
• Inconsistent indentation. You should be able to where you are in a nested if/loop/case/whatever by the indentation.
  
• Unnecessary cleverness. If you don't need to invoke an advanced language feature or complex programming technique, DON'T. If you are being paid to develope a program, you are being paid to make it work according to the specification and with a reasonable level of performance. Don't waste time trying to squeeze a few nanoseconds out of a routine that is going to be executed once or create an algorithm that while ingenious, cannot be debugged by an average programmer. The most brilliant programmer I have ever worked with was a master of making code extremely simple.
  

I couldn't agree more with the first item. This is especially annoying in PHP (my favorite language, unfortunately) due to the fact that there is no standard or followed rule for whether or not $needle or $haystack comes first. Ridiculous, imo.
I don't think a single page is long enough for modern code, but I can agree with keeping them small. I think this would be most annoying if parts of the large chunks were used repetitively across multiple functions, e.g.
function a(x) {
cal(); cu(); late(); value(); mass = of(x);
return mass;
}
function b(x)
{
cal(); cu(); late(); value(); volume = of(x);
return volume;
}

Can be much simplified with:
function calculateValue(){ cal(); cu(); late(); value(); }

For the last, I can agree with not squeezing out nanoseconds from a single-run code, but I think said saved time should be practiced elsewhere solely for the practice, so that it becomes second nature instead of an extra task.

I also think that it doesn't matter if your program can be interpreted by anyone other than yourself, for the reasons stated before. If someone else is working on my program, it means I'm not getting paid, in which case I don't care for their convenience. It only makes better monetary sense to make your code only interpretable by you - in the sense that it's still legitimate code and not deliberately fudged.

[BFD]

Nov 23, 2010 22:38:46 GMT -8 Charles Stover said:

I also think that it doesn't matter if your program can be interpreted by anyone other than yourself, for the reasons stated before. If someone else is working on my program, it means I'm not getting paid, in which case I don't care for their convenience. It only makes better monetary sense to make your code only interpretable by you - in the sense that it's still legitimate code and not deliberately fudged.

Wow...I hope you are kidding, as that is a downright brutal mentality to have as a professional software engineer...and very limiting in terms of the environments you can successfully work in. And it doesn't make monetary sense to me, as it pretty much eliminates the use of past customers as references or relying on repeat business.

Then again, I probably should hope all of my competition operates as you profess...

[Charles Stover]

Nov 24, 2010 13:50:40 GMT -8 BFD said:

Nov 23, 2010 22:38:46 GMT -8 Charles Stover said:

I also think that it doesn't matter if your program can be interpreted by anyone other than yourself, for the reasons stated before. If someone else is working on my program, it means I'm not getting paid, in which case I don't care for their convenience. It only makes better monetary sense to make your code only interpretable by you - in the sense that it's still legitimate code and not deliberately fudged.

Wow...I hope you are kidding, as that is a downright brutal mentality to have as a professional software engineer...and very limiting in terms of the environments you can successfully work in. And it doesn't make monetary sense to me, as it pretty much eliminates the use of past customers as references or relying on repeat business.

Then again, I probably should hope all of my competition operates as you profess...

Not at all. Like I said, as long as you aren't deliberately using horrible code. Why would a past customer not hire me again when my code parses faster and uses less memory to do the same job? Why would they want to hire someone who can't understand optimized code? You're essentially arguing that an engineer should use math that an algebra student would understand, and that if they use shorthand, more efficient, faster to read and compute math, then that the employer should never hire them again and instead look for an algebra student.

Code should never be dumbed down to support programmers who suck at programming. Ever. In all honesty, they shouldn't be hired in the first place if they can't understand the programming involved. So there may be an idiot-friendly alternative (like using if statements instead of inline, or calculating out various powers of 10 via guess-and-check instead of just using logarithms because 'someone might not understand what logarithms do'). That doesn't mean you should do it. If the proper method of coding is complicated, so be it. It is up to other programmers - especially programmers who work for hire - to learn the complicated and proper method. It is proper for a reason, be it speed, functionality, memory use, etc. That is resumé material.

If an employee were comparing me to some other applicant, and I were to say, "I can do the same thing with less code, have it run faster, and have it use less memory," it would be I who got the job.

I see no reason why I should remove a very useful skillset in website optimization that will allow me to do projects faster, with more features and thus better pay, so that I can cradle some hypothetical programmer who not only took my job [apparently since he's doing it], but also sucks at it, seeing as how he's not capable of doing the same things I do.

Where is the logic in that? Again, programming should not be "dumbed down" to support other idiot programmers any more than an engineer's Calculus should be dumbed down to support engineers who only passed Algebra.

Unnecessary cleverness. If you don't need to invoke an advanced language feature or complex programming technique, DON'T.

Someone who has passed Algebra II:
log10(100)

Someone who hasn't:
for ($x = 0; $x < 100; $x++)
{
if (pow(10, $x) == 100)
return $x;
}

In no scenario would it be better to hire the second programmer. Even though log10 is not needed, it should be used. There is no such thing as an unnecessarily complicated program - unless, as I made the exclusion, it is deliberately complicated, such as abstract variable and function names, lack of indents, etc. If there is a more efficient way to do a task, that is the way it should be done. Always. It doesn't matter how complicated it is. Any programmer working for hire should already be familiar with the most complicated tasks and be able to perform them just as easily as the simplest tasks.