I can't program because the code I am using uses old coding styles. Is this normal to programmers?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

• 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

Answer 5

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.

Answer 6

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 ...

Answer 7

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.

Answer 8

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.

Answer 9

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).

Answer 10

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.