Web Development

Five common programming mistakes

Justin James describes (and even confesses to committing some) programming gaffes and explains why these particular behaviors can be problematic.

A couple of weeks ago I talked about five common mistakes programmers make with databases. This week, I look at five general programming mistakes I see often enough that they deserve special attention.

1: Variable naming inconsistency

I don't care if you like Hungarian notation, camel case, Pascal case, or whatever, but you have to be consistent -- and not just with your casing but with the naming. For example, if you are passing around a Customer Number, do not call it "custNo" in one place, "customerID" somewhere else, and "custNum" in a third place. Each version keeps the same case, but each one appears to be talking about a totally different piece of data. This makes maintenance very difficult.

2: Date/time issues

I recently read a piece called "33 myths developers have about dates and times" or something along those lines, and the very next day I had to solve a bug because a previous developer on a piece of code persistently misunderstood if noon was "AM" or "PM" in the 12-hour format. I can't stand on the high road here, because I have made plenty of poor assumptions when it comes to date and time issues. I learned that you should not try to do these things yourself, and instead leverage your language's built-in date/time functions.

3: UI craziness

Every now and then, a UI idea, component, widget, or style will suddenly come into style, and the next thing you know, it is everywhere. This is fine when it is a simple matter of aesthetics, but when it comes to actual UI functionality, step cautiously. A good example is the massive menus that have become common on websites. While the menus may solve a common development problem, a lot of developers use them inappropriately, or push them onto an audience that do not understand them very well, and the result is a bad user experience. A similar issue is the use of certain UI metaphors that can be confusing to users, like drag and drop or the use of trees. These items are perfectly fine when used in moderation and in the right areas, but some programmers develop an infatuation with them and use them in all sorts of wrong ways.

4: Not checking the logs

I cannot tell you how many times I have heard a conversation that went like this:

Programmer A: Can you help me with this problem?

Programmer B: Sure. What kind of error message are you getting?

Programmer A: I don't know.

Programmer B: Have you checked the logs?

Programmer A: No.

If you haven't checked the logs to get the error message, how do you expect to find out the problem that needs to be fixed? A similar situation is when developers don't take the time to find the error message in other ways. For example, if something isn't happening in your Web app and JavaScript is involved, there is a good chance that a JavaScript error is preventing your browser from running any more JavaScript on the page. Simply opening the F12 tools in IE or Chrome, or Firebug in Firefox, and watching the JavaScript console for errors will likely put you on the right path.

5: Overdependence on code completion

I use a lot of tools that perform code completion. In a typical work day, I spend at least some time within Visual Studio and getting to use IntelliSense, and for the bulk of my day I am head deep into Agile Platform's Service Studio, which takes code completion to new levels -- not only does it fill in and offer suggestions as I type, but in many places it automatically offers a list of things based on the type needed and what is in scope. This is a fantastic feature, but once in a while it bites me in the rear when I blindly take the wrong item just because it is at the top of the list or because it looks close enough to the actual choice I need. This isn't the tool's fault -- the error is between the keyboard and the chair. On the one hand, it speaks volumes about the quality of these tools that I trust them so much that I lost a lot of my vigilance; on the other hand, it is still my fault that I allow convenience to turn my brain off entirely. I have learned to slow myself down when using code completion and take the extra second or two to ensure that I have made the right choice.

J.Ja

Keep your engineering skills up to date by signing up for TechRepublic's free Software Engineer newsletter, delivered each Tuesday.

About

Justin James is the Lead Architect for Conigent.

49 comments
celinsmith111
celinsmith111

these all are basic mistake for beginners, variable is more out of this.

vjv.mabaso
vjv.mabaso

for(int x = 0; x less than max; ++x) ... In regards to the 1st point of the article, is 'x' correct being x? (or any letter of the alphabet for that matter...), because I've noticed that this is always the case... and y 'x'? who started this???

noraziah_ag
noraziah_ag

Yes, sometimes web developers are just too excited about the UI components capabilities that they use it inappropriately to make the website sophisticated and hopefully give that 'wow' impression to the visitors. But instead, it creates confusion and visitors sometimes find it not user-friendly. My advice is to make it as simple and straight forward as possible, and use those special UI only when it adds convenience to the users. And as for variables naming, have your own standards and make sure you and your teammates follows them strictly. If you use "cust_id" for customer identification number, use "cust_id" throughout your coding, may it be in javascript or php as long as it refers to the same item.

RMSx32767
RMSx32767

Documenting the obvious (e.g. increment counter) whilst not documenting what is the purpose of a variable or segment of code. Most of us can determine WHAT the code is doing but not perhaps WHY it is being done. Proving you are clever by writing a C program that generates the 12 days of Christmas. Nesting because you can, not because it is necessary. Remember folks, someone else someday will need to maintain your code and you really want that person to say "What a beautifully written program" not "He/she was either genius or an idiot and either way I hate this program."

Chaz Chance#
Chaz Chance#

I am constantly amazed at how many think this a good idea. It is lazy programming, and evidence of complete lack of planning.

anil_g
anil_g

This isn't even programming 101. Programmers need to accept that diligent detail to the level of paranoia is required all day every day every year they'll be programming. If they can't even apply consistency to variable naming they haven't got the right attitude. We all make mistakes but you'll make a lot more if your approach is wrong. If these mistakes are common we have a shortage of good programmers.

tooblessedtofail
tooblessedtofail

Great work Justin, you have listed quite a number of what we face almost everyday-I guess some tools help out more than others in different aspects you have mentioned. However, I think this list is too short :) So I am eagerly looking forward to a part 2. Probably titled: 10 very common mistakes made during programming!

Slayer_
Slayer_

I wish we could just check the log, but it just outputs the same error you got on screen. Useless.

alvalongo
alvalongo

Some programmers using Oracle's PL/SQL languague use explicit strings for dates and when execute the code the dates are wrong because they forget that explicit date convertion are different on IDE (TOAD, DreamCoder, SQL*Plus, SQLTools, etc) that on the server where the Oracle instance are running. I always recommend to use the function to convert string to dates ([b]TO_DATE[b]) and use the second parameter to format the string: TO_DATE('2012-09-01','YYYY-MM-DD').

David Stratton
David Stratton

I can't find it on Google or Bing. Has anyone got a link to this?

DCR-Mo
DCR-Mo

One of the biggest problems I see in some newbie programmers is wanting to start coding before they even know the whole problem. You have to spend judicious time in the design phase BEFORE you start coding. (OK agile enthusiasts, you can start hammering now...:-) . There are very few occasions where I can look back on a project and say "I wish I would have spent less time on design."

jcqs.bchrd
jcqs.bchrd

Hi, once I had to adjust timestamps in a log analysis. The adjustment was variable in duration and direction. Could be 'add 35 minutes' could also be 'subtract 56 minutes'. None of these operation is simple as you can change day, and/or month and/or year, not excluding leap years. The clue has been to convert original tiemstamp into a number of days and hours, apply the change and convert back to mm/dd/yy(yy) hh:mn:ss. For that kind of convertion the DATE routine of REXX has been a great help. Regards, Jacques

maxdev
maxdev

After the last compile. Plus overdependance on external libraries

CBIL360WebDesign
CBIL360WebDesign

Whenever we do programming someone stuck at the somewhere and start conversation without checking the logs.... it's not the character of any programmer before asking for help - we have to try all possible ways to recover from it.

Jaqui
Jaqui

what dimwit thinks a DESKTOP application does NOT need any menus at all? [ Chrome being the perfect example ] what shyte for brains thinks that 12 instances of a graphic widget uses less resources than 1 graphic widget instance with an array of 12 pieces of text? [ Chrome's address bar inside each tab being a perfect example of that idiocy. ] a web browser that makes it extremely difficult for you to open a file on your own computer to view it by not having a menu to give you access to that functionality is 100% useless. any application that changes ui design completely, said changes increasing resource consumption, needs to be redesigned. edited to add: why is it that our thousands of times faster computers, with millions times the resources, run so much slower that the older systems did? I recently got an i386 notebook, 16 mb ram, no cdrom, no space for a battery at all, black and white 800x600 display. the freaking thing boots, loads ANY application in far less time than a dual core system with 2 gigs of ram.

Mark Miller
Mark Miller

I've talked about this before on here, but it may be worth repeating. There's a temptation to lean on an IDE's application support features to design your app. for you. I discovered years ago this was a big mistake. Beyond editing, compiling, and debugging, use the IDE's features with caution. You could paint yourself into a corner.

Tony Hopkinson
Tony Hopkinson

The delusion that the code will not change. Everything else involved in the creation of any piece of software follows from that.

paradisewebdesigntx
paradisewebdesigntx

Trying to make #1 clear to my VB class, but they just don't get it. They are of course learning constants today, so more issues will come about. Yay...

mattohare
mattohare

SQL Server Management Studio's code completion can really get in the way. Type a short keyword, then space, and you can get something totally inappropriate. And, I always seem to forget to press escape to tell it to let me have what I want.

Slayer_
Slayer_

And after 'i', I use 'y' If I have to go deeper than two loops, I use better variable names.

Tony Hopkinson
Tony Hopkinson

I'd have worded it slightly differently, but the concept of not changing things until you know what you need to change, is a concept many should take home. Ever worked with someone who corrects bugs by successively fixing symptoms? :(

anil_g
anil_g

How many times have I come across some GENIUS comment like that (increment counter) while the bulk of the remaining MESS is completely undocumented?

anil_g
anil_g

Sometimes this is cost / effective. Python is sometimes used like this. I still wrestle with deciding when it is justified.

Slayer_
Slayer_

Line 1 error, so lines 2-20 are useless, skip them and go to the catch statement. Or function error, exit with a failed return code.

Mark Miller
Mark Miller

I remember dealing with this design issue when I first started into client/server software. Somehow I got acquainted with the kind of people who were using the client software (every application developer should do this), and I realized that the detailed error messages I was putting in the log were not appropriate for them to see. I wondered, though, "What would be appropriate?" I worked this through with my fellow developers on the project, and we came up with about three error messages that were "good for all occasions." We'd send those back to the user, using a little discrimination about which one to pick, and we kept the detailed error messages on the server log, for us, or the customer's administrator to see. If it was something that the user could correct, they were notified of it, and allowed to correct it. If it was a system problem, all they'd see was something like, "Transaction failed. Please contact administrator." What we realized was that the issue of error messages was really about delegation of responsibility, and then considering how much responsibility each person who might see it was capable or authorized to take on.

Chaz Chance#
Chaz Chance#

If the log file can't tell you what is happening at the moment before the error message, you might as well not bother.

Tony Hopkinson
Tony Hopkinson

By me, in the top five database development mistakes. Though I've seen people carry it through into code as well. StrDate = ..., instant shudder of apprehension.

Tony Hopkinson
Tony Hopkinson

:D There's only one that seems to be prevalent and that is that "01/07/2012" is a date...

jimcakalic
jimcakalic

Agile methodologies don't advocate NO design as many people (even some agile practicioners I've met) mistakenly believe. The de-emphasis on design is a) because that activity does not provide the feedback necessary to know if the intended approach will work and b) a "design" is an abstraction. Agile methods encourage doing "just enough" design to set a direction. And they discourage being too formal in capturing the design (one reason is that doing so causes one to become attached/invested in the original design to the extent that it can become a constraint on the implementation instead of a guide). I like to point out that in Robert Martin's book , Agile Principles, Patterns and Practices, he takes up a payroll case study and spends a whole chapter analysing use cases, deriving class hierarchies and drawing sequence diagrams before the first line of code is written. So true agilistas don't completely eschew up-front design, just BIG up-front design.

Tony Hopkinson
Tony Hopkinson

You can design by having a go. The real problem is when you use this approach you need to be ruthless. If it turns out your design is lacking, bin it, and use the lesson. Don't rescue it, don't patch it, don't leave it for version 2. Now in the commercial software world, when v1 with it's technical debt has been delivered, what has actually happened. While I wholeheartedly agree with you that time spent designing before you put your two fingers on the keyboard is time well spent, businesses in the main do not share our opinion. As long as they can sell it, it will do. Spiraling maintenance costs and no longevity are out of scope. It's another area where academia could improve as well with some more real life scenarios, than swap this bubble sort for something more efficient.

sysop-dr
sysop-dr

I get asked to make apps and no-one has really thought of what they need, just what they want (not the same thing) so prototyping is the only answer. Yes not the same issue you are having but a lot of people seem to think that I am doing what you describe. Just remember, never use any of the prototype code in the final, it will always bite you if you do.

Tony Hopkinson
Tony Hopkinson

Always feels as though I've let myself down. Learning how to ask was one of the hardest things I had to do, shifting from the one man band I used to be, to being part of a team.

Tony Hopkinson
Tony Hopkinson

for coping with the bloat around backwards compatibility, supporting huge frameworks, unnecessary features, marketing gee-whizzery and running someone else's code for "your" benefit. The personal computer is dead, now we have the personal appliance, progress in it? Now whether this is result of poor practices in programming or excellent business practices, is a bit of a chicken and egg question. :p

333239
333239

Following on from that, the delusion that you only need to write code that computers understand, when it is much more important to write code that humans will understand. Surrounding every line with verbose comments does not make code more readable either.

Chaz Chance#
Chaz Chance#

When I used to teach (in those days Windows (1) ran from a 5 inch floppy and the 80286 processor was golng to solve all computing problems because it could addess a whole megabyte of RAM) I would have the students create a fairly complex piece, then work on something different for a while, then come back and make some changes to their original code. That got the naming and style consistency points across.

Marc Jellinek
Marc Jellinek

Same issue here. Some days it gets to the point where I just turn it off. It does require some interesting keyboard gymnastics. I find myself writing the FROM clause first, then up-arrow-ing back to the SELECT clause... a very un-natural way to write code. For every stupid mistake it keeps me from making, it seems to introduce two more.

Mark Miller
Mark Miller

[i]"Ever worked with someone who corrects bugs by successively fixing symptoms?"[/i] Is that just another way of saying that they try to do a work-around, rather than fix the problem? Sometimes that's unavoidable, since fixing the problem in one place could cause LOTS of problems elsewhere.

Mark Miller
Mark Miller

We all know that exceptions are supposed to be used for exceptional error conditions, but I think he was saying that rather than, say, returning from a function once a process is done (no errors), the programmer throws an exception instead to alter the flow control in the function that called it. So rather than using a conditional in the calling function to test a returned value, the programmer sets up a try-catch in the calling function that basically works like: try { askUserForSelection(); // If they pick option A, execution will begin here } catch(choiceException) { // if they pick option B, askUserForSelection() will throw this exception, // and execution will begin here. } Another "idea" is to use an exception to break out of a loop, even though it's a lot easier to just use a break command inside the loop.

Marc Jellinek
Marc Jellinek

I would have hated to work on your helpdesk.

Tony Hopkinson
Tony Hopkinson

It will be version 1 before you can realise what a terrible error you just made. :(

Slayer_
Slayer_

Last time it was just to design a jeopardy like game. Luckily they accepted my first design, but I went overboard in making it customizable, every image, shape, text, everything was controlled by INI files and the questions/answers and scores, players, etc. all stored in XML.

Tony Hopkinson
Tony Hopkinson

works. Another good one is to get them to swap code bases through the lifetime of a piece of software. So they all do question 1 on a piece of software, the question 2 is adding another feature to someone else's version. Make sure the swaps are random though. Then have class meeting agree some standards, then swap again for part 3. Round 4 is outside when the ignorant who didn't get it, and the too clever to bother with standards types, get to understand peer pressure. :p If they actually learnt this in academia instead of stuff like O notation, the industry would be way better off.

mattohare
mattohare

... keyword, space and enter before typing the FROM clause. Then up-arrow. Now that I think of it, we can type the FROM clause on the line, then Ctrl+Enter to get the fresh line inserted. Really, I don't mind the gymnastics, but my hands are too old for the contortionist forms.

Mark Miller
Mark Miller

What I describe was when we used GUIs for clients, in client/server arrangements. We didn't have "sessions." Instead we had momentary connections between the client and server, to send/receive data. State was maintained during the connections, and then lost once the connection was closed, though a little state (about retrieved/updated records in the database) was maintained long-term on the server. Some of our engineers had worked closely with the end users, both administrators and client users, to see how much responsibility they could exercise if something went wrong. I personally did not. That was something I begged my bosses about, but they only wanted to send senior engineers, to save money. I just took direction from them. My point was, from my perspective, that I *asked*, before going ahead with a messaging design, what the administrators and end users were capable of if something went wrong. Sometimes we had to step in to fix specific errors, because no one on their end was capable of handling it. At least that was the case in the short-term. Ultimately, they sent out their engineers to our office to find out how our software worked, so that they could take over full maintenance.

anil_g
anil_g

Yes, now that you point that out that could be awkward. Possibly the wording of the error message could be improved without reducing available detail. Common practice is to put a prominent large font user-oriented warning but include technical detail in low contrast so that it's available if helpful. Some users are more savvy and can possibly work out a course of action based on which area the fault occurred in. An on-site technician who doesn't have immediate access to the log may be able to solve immediately if the fault is clear. Also cross-referencing the particular error for any one user to a large volume log may be non-trivial. I wonder if this post indicates a 6th type of programmer error: not consulting users on features and behaviour? Mark says "know thy user" but he then says "I realized" and "I worked this through with my fellow developers". No other stakeholder consultation involved? Sometimes errors are not really errors, like an expired session that is reported as a database error, or a failure to delete is legitimate because there's additional referenced content, but this is not explained. But that's another problem and definitely requires direct communication to the user, not obscuring it.