Take the 2-minute tour ×

I have my first real job as programmer, but I can't solve any problems because of the coding style used. The code here:

  • Does not have comments
  • Does not have functions (50, 100, 200, 300 or more lines executed in sequence)
  • Uses a lot of if statements with a lot of paths
  • Has variables that make no sense (eg.: cf_cfop, CF_Natop, lnom, r_procod)
  • Uses an old language (Visual FoxPro 8 from 2002), but there are new releases from 2007.

I feel like I have gone back to 1970. Is it normal for a programmer familiar with OOP, clean-code, design patterns, etc. to have trouble with coding in this old-fashion way?

EDIT: All the answers are very good. For my (un)hope, appears that there are a lot of this kind of code base around the world. A point mentioned to all answers is refactor the code. Yeah, I really like to do it. In my personal project, I always do this, but... I can't refactor the code. Programmers are only allowed to change the files in the task that they are designed for.

Every change in old code must be keep commented in the code (even with Subversion as version control), plus meta information (date, programmer, task) related to that change (this became a mess, there is code with 3 used lines and 50 old lines commented). I'm thinking that is not only a code problem, but a management of software development problem.

share|improve this question
Yes of course it's normal. You've been trained to work a certain way, and most of your training is useless when facing a codebase that was implemented on a quite different way. That said the core principles haven't changed that much, and after the initial shock you'll start adjusting... –  Yannis Rizos Apr 5 '12 at 18:25
You aren't missing much by not using comments. If anything people overuse them. –  JohnFx Apr 5 '12 at 18:30
@JohnFx Not disagreeing with you, but having faced more than few commentless legacy crap, I'd say I prefer redundant / obsolete comments than no comments at all. –  Yannis Rizos Apr 5 '12 at 19:42
This will seem evil - but I'm glad you are feeling this kind of pain early in your career, as it will be a great motivation not to write code like the kind you are maintaining. –  Bork Blatt Apr 5 '12 at 19:46
One of the most important skills you can develop as a programmer is to be able to understand and refactor other people's code. If you don't master it, you'll never be a good programmer. You're fortunate in being given a chance to learn the skill. –  Paul Tomblin Apr 5 '12 at 20:48

10 Answers 10

up vote 7 down vote accepted

This sounds to me like an Opportunity.

It's clear that you already can see lots of problems in how things are done and managed. You can either complain that it's all rubbish and that you can't do anything, OR you can use this as a golden opportunity to really show your employer your worth.

Now, it's not going to help you if you march up to your employer and tell him that everything needs to change. So the trick is to play along for a while, ask LOTS of questions, and when you are required to write code you'll need to play by their rules with all of the comments etc, as you are going to need to keep other developers informed using whichever system they presently prefer, while at the same time you can introduce sensible refactorings that won't risk you anything. You can extract a couple of methods, and if your language supports it, introduce a few unit tests. When asked why you've done it this way, or if told you're doing something "wrong", avoid getting defensive or argumentative while making a sound presentation of your position for your preferred style of coding. For example, you can refer to books such as Bob Martin's Clean Code, or you can refer to other books, articles, or even questions and answers that you have come across on Programmers.SE. Anything that you can find helpful to support your position with facts that might be beyond your experience in the eyes of the people you are working with.

With regards to the excessive commenting, some of this can be cleared up if you were to add in a few descriptive names for the variables and methods, but you might also be able to make a case for a good version control system, and using that to keep the record of the changes and dates etc, and for the use of a tool to compare the different versions of your source files if one doesn't already come with your chosen VCS.

Like I said, this is an opportunity to contribute to the improvement of a development team that sounds like it's kind of lost its way so to speak. You have the opportunity to stand out as skilled and knowledgeable, and as someone who can lead by example. These are all good things to help you later as your career progresses.

share|improve this answer
First, all answers here are good and helped me. This answer was not high voted or commented, but I really like it. I think that point of asking a lot of questions and not going on defensive are very important. I talked to my boss about some points I mentioned here, and as expected, I don't have the power to do big changes, but I feel that a bit will be changed for better after that. Thank you, S. Robbins and the others for the wise words. –  Renato Dinhani Conceição Apr 16 '12 at 12:46
Well I did that once, and succeed at it. It is exhausting. I'll never do that again. This is really hard : you can't unittest BEFORE refactoring, code is weak so is likely to explode on your face at any moment, and you will face a very important resistance due to people's working habbits (among other problems). I know work only for people that care about code quality. –  deadalnix Jun 12 '12 at 8:33
@deadalnix First jobs rarely offer the opportunity to choose the people you work with. Often you won't know how much people really care about code quality until you've worked with them for a while. My answer helps the OP understand this. Your statement about an inability to unit test before refactoring is patently wrong. Trying to refactor before unit tests increases overall risk. Chasing bugs without tests is inefficient and exhausting. People who care about code quality focus heavily on tests and clean coding technique. I don't get your implied objection, happy to chat about this offline :-) –  S.Robins Jun 12 '12 at 9:13
@S.Robins Chasing bug without test is inefficient and exhausting and refactoring without unittest is very risky (and both combine nicely). This is exactly why such a situation is a nightmare. Massive legacy codebase aren't usually unittestable (full of global states, hardcoded dependencies on production system, or on other systems, no separations of concerns, massive code repetition, etc . . .). You'll have to go throw a first refactoring pass to make the code unittestable. I think we both agree on the coding aspect of the problem, but misunderstood each other. –  deadalnix Jun 12 '12 at 9:38
It's also an opportunity to gather content for thedailywtf.com –  Arkh Jun 12 '12 at 10:23

This coding style (if you even want to call it any kind of style) is bad coding style.

One can write short functions with descriptive variable names and sane flow control in most modern languages (Visual FoxPro is modern, yes).

The problems you are having are with a bad code base, nothing more, nothing less.

Such codebases exist and are many - the fact that you are having problems with them attest to how bad they can be (and that you have good training).

What you can try and do is improve on things where you can - rename variables, extract commonalities and divide large functions into smaller ones etc... Get a copy of Working Effectively with Legacy Code...

I am on a C# project with very bad structure, not miles off what you describe. Just combined 12 separate functions (obvious copy-paste) into one that takes a single parameter.

share|improve this answer
Good programmers can handle any kind of horror story. It won't be fun, but that's why they pay you money to do it. Work is not supposed to be fun and games. –  tp1 Apr 5 '12 at 18:42
@tp1 - Yep, but you must admit that the first such codebase you encounter can be quite a shock to the system. –  Oded Apr 5 '12 at 18:47
@Renato: all programmers work on maintaining code far more than writing/designing new code. And all code that is constantly being modified gets worse over time unless you spend a lot of effort to prevent it. Good programmers are also better at dealing with bad codebases, whether they like doing so or not, so managers will often give them such tasks, and few are in a position to completely avoid such tasks. I would actually argue that a programmer cannot claim to be truly good unless he has some experience dealing with bad code (which may well be his one). –  Michael Borgwardt Apr 5 '12 at 19:31
@RenatoDinhaniConceição, I would never consider hiring a developer to do original design who hadn't done his or her time in maintenance, you CANNNOT be a good designer without this experience (failing to do this is one of the top causes of bad designs in my experience). You cannot be a good programmer and be bad at maintenance. You may not like it, but it is necessary to understand how to design well. And the ability to do hard perservering work is also a characteristic of a good programmer. If it was easy they wouldn't need us. –  HLGEM Apr 5 '12 at 20:28
@Myrddin Emrys: If you have never programmed in a team, you are an amateur programmer with a limited skillset, and about as likely to be a truly good programmer as someone who's spent years studying chess without ever playing against an opponent is likely to be a truly good chess player. –  Michael Borgwardt Apr 5 '12 at 23:03

That's not really "old fashioned" except in that (current) good design practices weren't always as popular. That's just bad code. Bad code slows anyone down. You eventually get used to it, but that's just because you get used to specific quirks in your specific system. Given a new project you might find whole new ways to write bad code. The good thing is you know how to identify these code smells already.

The biggest thing you can do is don't propagate the problem. Don't take these bad practices as a convention unless your team is. Keep new code clean in ways that don't force a refactor. If it's that bad and you have time, consider a major refactor...but in practice you rarely have that luxury.

Consider adding comments as you figure things out, and change little bits and pieces as practical. Unless you're coding solo you need to work this out with your team; if there's no conventions you should take some time to come up with them, and maybe commit to slowly improve the code base if you're regularly maintaining it anyway.

If you find a totally isolated function with bad variable names and you're fixing it anyway, you might as well make the variable names something useful, refactor the ifs. Don't make changes to common features unless you're going to refactor a large portion of it.

share|improve this answer
"good design practices weren't always as popular" It's not necessarily about popularity. What's considered good design or best practise evolves over time. It's something to bear in mind when looking at old code. –  Burhan Ali Apr 5 '12 at 21:01
@BurhanAli, abosiolutely, what was a good practice in 2000 when our application was orginally designed is not necessarily a good practice now. The younger developers often have no idea that what they were taught as best practices may not have existed at the time the code was written or may not work with the older language the software uses. –  HLGEM Apr 6 '12 at 14:06
I don't think 500-line functions were ever considered "good"... the primary book I learned assembly from back in the 80s mentioned that you should maybe break things into subroutines when they started getting too big to branch from the end back to the start. That comes to somewhere between 40-120 lines on that processor (6502). –  mjfgates Apr 6 '12 at 17:35
  • don't have comments - fix it as you learn it
  • don't have functions (50, 100, 200, 300 or more lines executed in sequence)

This probably dates from a previous iteration of the code. At this point, I'd beware of subtle differences between similar-seeming code blocks that have become "features". But regardless of how bad an idea this type of structure is, it is pretty simple to understand... so I'm not sure where you'd have trouble with it.

  • uses a lot of if statements with a lot of paths - I'm not actually certain what you mean here
  • has variables that make no sense (eg.: cf_cfop, CF_Natop, lnom, r_procod) -

I would emphasize caution with the 'renaming variables' bit. There's a fair chance you simply don't understand the lingo yet, and the variable names will make much more sense after you've been there for a while. Not to say that there can't be problematic variable names as well, but your examples look like there is a logic to them, if you knew what the common acronyms at your site are. This is obviously not as important if you're a team of 1.

  • uses a language I am unfamiliar with (Visual FoxPro 8 from 2002) - This is your issue, not the code's
share|improve this answer
+1 : This is your issue, not the code's :) –  aleroot Apr 5 '12 at 21:13
His last point was grammatically incorrect; I could not understand his original meaning. I guessed, and I may have guessed wrong, so he may not have meant that he was unfamiliar with Visual FoxPro. –  Myrddin Emrys Apr 5 '12 at 21:59
About FoxPro, my question was edited. I said that is a verbose language and for me, this is not good, but it's a personal opinion. I understand it, but I don't like, and the main point is the age of language. It was not updated in my company, but there are new releases (Visual FoxPro 9 from 2007). –  Renato Dinhani Conceição Apr 6 '12 at 3:05
@RenatoDinhaniConceição, it is common not to upgrade a database product as upgrades break things that currently work and there is no money or time to spend to make changes you don't need to if you maintain the older version. This is a business choice. –  HLGEM Apr 6 '12 at 14:09
@renato, most database applications are not easily backward compatible. –  HLGEM Apr 6 '12 at 14:45

Welcome to the jungle !

Unfortunately, often start working in a company means start facing these kind of situations, unless you work for a structured and well organized company, this situations are quite usual ...

My advice is :

  1. Start learning and get familiar with : programming language used(Clipper/dBase) and environment(Visual FoxPro)

  2. Read and Analyse the code base and start commenting it

  3. organizing/refactoring the code (addressing the problem of too many lines executed in sequence)

Having problem facing a similar codebase it is normal, but can become a great challenge trying to improve the code quality and giving "your touch" to the program improving the codebase and maybe making it a better program ...

share|improve this answer

To answer your question: Yes, people/companies everywhere utilize infrastructure which may be built upon crappy code. When integrating yourself into such situations, it can be very hard to deal with.

Last summer, I worked as an intern developing an application to be used by the QA team attached to a specific department. The QA team used a lot of standalone scripts (VBScript, Perl, Bash) to run tests on databases and such, and they wanted to bring them all together into one application. The problem with this, however, is those scripts were used elsewhere in the company (thus core functionality/variable names couldn't be changed), and the code was "added to" for almost 10 years; a lot of crap had built up.

Here's what you can do about it, though:

  1. Ask for help: your fellow coworkers who have had to look though this code are probably familiar with its idiosyncrasies. What is obtuse and confusing to you is perfectly fine for them. So ask for help!
  2. Refactor whenever possible: if you have to look at/maintain this code for an extended period of time, refactor it whenever you can. Even if you're running a find and replace on a variable name, every little bit helps. That company I interned for last summer had a similar problem of using crappy variable names. Every chance I could I ran their code through a fine-tooth comb, changing variable names, optimizing logic (grouping various functions together into 1, for example), etc. Do the same whenever you have the opportunity!

As is the case everywhere, as long as the external features of the code work properly, it won't matter how the internals work.

share|improve this answer
+1 for "ask for help". Working in a team adds costs but also brings benefits. –  Jon of All Trades Apr 6 '12 at 16:20

I am going to make some comments that are different from many of the responders here. Many of my comments may be obvious to you, but need saying anyway.

  • Be cautious of changing code that you don't understand, until you understand it.
  • If you are working in a team environment, with code that your teammates work on, discuss your changes with them before making the changes. Nobody likes a "lone gunman" to come in and change code with which everyone else is familiar. This is not to say that your changes are not warranted or the "right" thing to do.
  • Gain adoptance for your ideas. Get everyone on board with your ideas, then you can use the skills of your team to refactor, instead of burdening yourself with the whole workload.
  • Gain management buy-in. They may be able to allocate funds for you to go and re-factor the code.
  • Speak to management in terms they understand about the benefits of re-factoring their code-base. More maintainable code means less time spent resolving bugs, adding features etc. Which means cost-effective development. Faster turn-around time etc.

It's easy to add pure coding, best practice suggestions without understanding the politics of your environment. The people you work with may not want to change, or allocate the time to changing your code base, but try to sell the idea to everyone before jumping in and changing everything (which has inherent risks in and of itself)

Hope this helps.

share|improve this answer
Also: Test, make backups, use version control. If you're new, there are things going on in the source that you just won't understand, and what looks like an innocuous change can cause issues you don't foresee. –  Scott Wilson Apr 6 '12 at 17:26
I would further add. Don't change anything until you have a failing test that demands action. Start writing tests. When you have a failing test, make sure it matters. Then you have a strong mandate to change. Even then wait until the system is saturated with tests. Always try to leave the system as good or better (never worse) than you found it. –  emory Apr 23 '12 at 7:37

One of the things that sticks out is your edited comment

Every change in old code must be keep commented in the code, plus meta information (date, programmer, task) related to that change (this became a mess, there are code with 3 used lines and 50 old lines commented). I'm thinking that is not only a code problem, but a management of software development problem.

I also have a project where I inherited a legacy FoxPro code base with many of the issues that you describe. One of the first things I introduced to the project was a good source code repository. FoxPro can integrate with SourceSafe, but that product is painful to use.

I grabbed a copy of Paul McNett's scx tool http://paulmcnett.com/scX.php and integrated that into my development cycle. It does a pretty good job of extracting the binary FoxPro code to a text format that can then be put into a source repository, like Subversion, Mercurial, or even git. (You might find the SubFox project at http://vfpx.codeplex.com useful.

These tools provide the History and allow the programmers to get on with the job of maintaining the code. It definitely takes some time to learn to use these tools, but since they are all free, it doesn't really make sense not to invest some time into them. (even if you can't get the Job projects moving that way).

share|improve this answer

I am going to strongly agree with funkymushroom's answer. If you are a team environment make sure others know you are refactor or reorganizing code, if you ever plan to get any good future assignments.

From personal experience I know, while not your style of coding, if you are maintaining code, which other also modify and maintain, stay in the style of the existing code. Adding comments and clarification is fine, but the basic layout and conventions should remain. The old gurus/guns on the project expect the code to be similar to what they have been seeing for years.

When a customer is screaming about a bug, your management will go to the old guns to fix the problem as quick as possible. If these old guns, when under pressure, find you “cleaned up the code” and so they now have to spend time figure out where you moved or renamed that one variable they know needs tweaking, your name in the company will be changed to “mud”.

Once the crisis is over, first the old gun will blame you slowly down the critical update. Next you will find that you get to keep maintain the cleaned up code for as long as you are at the company. Finally, when new interesting projects become available, your managers will ask to the gurus on who should work the project, and if you have screwed them once, you will never make it to the new project, until your fodder being thrown in at the end to meet a deadline.

If you learned in college the “right” way to code, and you are now in the workforce, forget that “right” way. These are not college assignment, these projects don’t last just a semester, they can live for years, and will have to be maintained by a group of people with different levels expertise and different levels of interest in the latest CS trend. You have to be a team player.

You can be the biggest hot shot programming in school, but in the work place, your first job, you a newbie with zero street cred. People who have been programming for years don’t give a hoot about your school or grades, it is how well do you play with others and how much disruption you bring to their lives.

In my 20 years, I have seem multiple ace programmers fired, mainly because they demand to do things their “right” way. Unless you bring something very, very, very unique to the job, you are replaceable. You may have been top of your class, but next year, someone else will be top of their class, and looking for a job.

I look at it as your primary job, is to keep your job, until you decide to change jobs. To keep your job means you have to play nice in the playground someone else built and paid for.

I know I sound negative, but there is always hope. As you gain experience, have success, you will gain influence, and be able to shift things to a better way. When writing new code or on a new project, push for the changes you seek. If it is new code, the old guns don’t expect it to be the way they left it, and when they see the advantages they might learn and adapt the new way.

Old system can change, but it takes time. Changing something introduces risk, and business hate risk, and you have to take time and work to make the company comfortable with the change.

share|improve this answer

Ok, I'll be blunt. That is a bad place to work... I've been in such situations, and usually it ends with you being swallowed by this code. After a year or so, you'll get used to it, and you'll loose the grip on how modern alternatives can be used to achieve the same task easier, in a more maintainable way, and also, faster at run-time in most cases.

I left a workplace like that, because, after just a month, I felt I'm being dragged into an old skool code. I tried to give it a go, but decided not to. I couldn't use clean code and started to loose skills because of missing everyday practice. Any modern approach had to be approved by 3 layers of developers, which never happened, because the idea was that things might break when modern approaches are used. And fragile nature of the code that comes out when you don't use modern approaches is quite scary.

Don't get me wrong, there are cases where people over-engineer solutions, and I'm all against it. But being dragged into '80 coding conventions and style for extensive amount of time will stop your progress, and also, I think, career opportunities.

Then again, you have to earn money, so sometimes you have to do what you don't exactly like. Keep an eye on burnout symptoms and turning coding into a mundane task in those cases though.

share|improve this answer
How can you say its a bad place to work? There is nothing wrong with legacy inline code. Legacy code has a place in this world without legacy code we would have new exploits in applications we use daily. –  Ramhound Jun 12 '12 at 16:15
@Ramhound: Because I have first hand experience in such places. You are not going to be allowed to use effective containers, you are not going to be able to use safe constructs, you will have zero input on architecture. The scare of change being the main reason. And if you stay in such place for more than a year, you will be dragged into it. Modern code makes your designs simpler, faster and SAFER! I'm pretty sure the place is full with raw memory twiddling, on the fly SQL query construction, most likely not even parametrized, and so on. –  Coder Jun 13 '12 at 9:05
@Ramhound Legacy code is ok. Writing legacy code today is not ok. –  Renato Dinhani Conceição Jun 15 '12 at 14:00
@Coder, this is was a perfect description of the job, and like you, I left the job after a month and a few days. The best thing I did, and now, in my free time, I'm learning a lot of useful things. –  Renato Dinhani Conceição Jun 15 '12 at 14:04

Your Answer


