29

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.

hippietrail
  • 263
Renato Dinhani
  • 3,005
  • 43
    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 Apr 05 '12 at 18:25
  • 12
    You aren't missing much by not using comments. If anything people overuse them. – JohnFx Apr 05 '12 at 18:30
  • 2
    By all means, improve this terrible code as you change it. Add comments, refactor, rename variables sensibly. Since such transforms make code simpler and easier to read, people mostly welcome them. – 9000 Apr 05 '12 at 18:31
  • 2
    Is something coded in a completely different manner than a developer is used to more difficult for the developer to maintain? That's a self-answering, rhetorical question. – GrandmasterB Apr 05 '12 at 18:37
  • 22
    @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 Apr 05 '12 at 19:42
  • 25
    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 05 '12 at 19:46
  • 1
    IMO, bad coding style has nothing to do with old coding style. Old coding style can be cool, and you don't need subtyping to get a good programming style. – BenjaminB Apr 05 '12 at 19:55
  • 19
    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 05 '12 at 20:48
  • 4
    Always remember that there might be very good reasons for things to be the way they are. Investigate and learn before dismissing because you think you know better. When you know the reasons you can evaluate if you think they are good or bad yourself. –  Apr 06 '12 at 06:09
  • 2
    You know what shitty codebase means? Time to help http://thedailywtf.com/ get more content. – Arkh Apr 06 '12 at 08:37
  • 1
    @PaulTomblin "I'm hitting you with this hammer for your own good. It'll help you to survive when I hit you with a truck." – deworde Apr 06 '12 at 10:29
  • Reads like a bunch of Cobol programmers were turned loose with FoxPro. Reads like the Cobol source code management practices from the 1970's are still in effect. You have my sympathy. – Gilbert Le Blanc Apr 06 '12 at 13:05
  • 3
    Wait...you're commenting edits in the code? Aren't you using version control? If not...why the hell aren't you using version control and why aren't you installing version control right now? – Ben Brocka Apr 06 '12 at 14:13
  • 2
    @BenBrocka Subversion is used as version control, but even with, keep the old code is needed. One rule is that two programmers can't change the same source file, even if in different parts because one commit will overwrite the other. So... I think they don't know the real usage of source control. – Renato Dinhani Apr 06 '12 at 14:18
  • Do you guys not use commit messages? I don't see why any of that is "needed". Comments should explain what something does but not what was changed. – Ben Brocka Apr 06 '12 at 14:23
  • 1
    @BenBrocka Is needed because this is the company rule, not because is REALLY needed. The commit messages are the date, programmer name and code of the task that the developer was doing. The comments in code follow same pattern, but instead the code of the task, it is a brief description of the task the programmer was supposed to do, not what is really going on the piece of the code below the comments. – Renato Dinhani Apr 06 '12 at 14:30
  • 2
    Looks like you are going to have a lot of material that can be submitted to The Daily WTF – Aditya M P Apr 06 '12 at 14:34
  • 1
    I must apology, my first though was that you were yet another case of a newbie discovering that the world isn't perfect, but I've never worked with such a bad process and rarely hear about equivalent one, and that was a long time ago. Here "your" process is fucked up and need to be fixed before anything can be done to improve the code. – AProgrammer Apr 06 '12 at 14:56
  • Agreed with @AProgrammer, this sounds like a bigger problem than the typical "yeah our codebase is ugly". Make sure you peruse our questions on version control, maybe make a separate question unless you find what you need in current questions. – Ben Brocka Apr 06 '12 at 15:24
  • Why closed? Asking if having difficulties to program in a bad way after learning the good way is normal is not a real question? – Renato Dinhani Apr 07 '12 at 20:07
  • "I feel like I have gone back to 1970.": Back then, there were OOP (Simula 67) and FP (LISP) already. I think the code you are working with is bad code rather than old-fashioned code. – Giorgio Apr 09 '12 at 18:39
  • 4
    After the longest month, I left the job. The best thing I did. – Renato Dinhani Jun 15 '12 at 14:02
  • All the swearing in comments is not necessary. I had an experience like this long ago, combing through a mass of old code and finding entire sections, whole sets of functions, that were never called. I created a second version, pruned and refactored it, then tested it against the first version. After that, I made the alterations that were requested of me. Of course, this was a summer job and I had all the time in the world. Good experience. Like weightlifting: lots of useless work that makes you a better person. –  Dec 13 '16 at 15:18
  • Your questions also somewhat sounds like you're expecting your coding style to stay consistent. As you gain experience and move from company to company, you'll be exposed to dozens of coding styles, each with their positives and negatives. Ideally, you'll incorporate the positive practices into your own methodology, so you'll continually evolve into a better developer. So, long story short, keep an open mind as you encounter other people's code that's different than yours. You'll see a lot of stuff that's "bad", but you'll also encounter some neat things that you'll take with you as you grow. – Ellesedil Jan 04 '18 at 19:16

10 Answers10

35

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.

Oded
  • 53,586
  • 19
  • 167
  • 181
  • 33
    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 05 '12 at 18:42
  • 9
    @tp1 - Yep, but you must admit that the first such codebase you encounter can be quite a shock to the system. – Oded Apr 05 '12 at 18:47
  • 4
    @tp1 Maybe I'm confusing something or my concept is different, but IMO, good programmers design the best solutions, what language use for each case, etc... In this case, handling this code base is more to hard persevering work than being or not a good programmer. – Renato Dinhani Apr 05 '12 at 18:55
  • 1
    @Downvoter - care to comment? – Oded Apr 05 '12 at 18:59
  • 1
    Well, the language, architecture and the design of the system is only decided once. But these systems last 10-15 years, and there is some hard work between the design and the time when it's discarded. – tp1 Apr 05 '12 at 18:59
  • 2
    @tp1 - Indeed. But clean code and descriptive variable names are not all that new... – Oded Apr 05 '12 at 19:00
  • 1
    @oded: last time I saw something like that, it was done to make the code look more difficult, so that newbs don't go changing it that often. Only people who could see past the variable names were able to modify it. – tp1 Apr 05 '12 at 19:04
  • 1
    @tp1 - Job security FTW! – Oded Apr 05 '12 at 19:06
  • @oded: or hide all the important bits inside complex stuff so that noone knows they're there :) – tp1 Apr 05 '12 at 19:08
  • 10
    @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 05 '12 at 19:31
  • 13
    @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 05 '12 at 20:28
  • 8
    @tp1 Work IS supposed to be fun and games, otherwise you're doing it wrong. – Kevin McCormick Apr 05 '12 at 20:41
  • 2
    @HLGEM - Diving back into maintenance every now and then is also good to give one a reminder of the pain involved in not doing things properly and cutting corners. – Oded Apr 05 '12 at 21:15
  • @HLGEM I would argue that you can be a good programmer, but be inexperienced at dealing with bad code. What if you have programmed for yourself for years, and this is the first code written by someone else you had to deal with? However, since dealing with poorly written and maintained code is a very core skill in the majority of cases, it's a valid point that you are far more marketable once you have experience dealing with bad code. – Myrddin Emrys Apr 05 '12 at 21:44
  • 6
    @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 05 '12 at 23:03
  • 3
    I believe it is incomparably rude to label all self-employed coders as amateurs. Indie game developers, one-man software shops... they exist, and are a significant (if small) portion of the programmer population. Not all coding is done in teams, even if the majority is. – Myrddin Emrys Apr 06 '12 at 01:31
  • 1
    Simply dismissing with an emphasized bad is perhaps jumping too quickly to conclusions. In my experience newly hatched programmers have a romantic view of the world and what is needed for production strength code. –  Apr 06 '12 at 06:11
  • @ThorbjørnRavnAndersen - dismissing? I am explaining to the OP why he is having a hard time with the codebase. It is because it is badly structured. Many codebases are like this, unfortunately, which I also alluded to. – Oded Apr 06 '12 at 12:48
  • @Oded, it does not have to be badly structured as such. This is his first real programming job - he might simply not be accustomed to how production quality software actually look with battle scars and all. If you have not actually seen the code yourself, I believe you cannot judge it as bad. –  Apr 06 '12 at 13:02
  • 2
    @ThorbjørnRavnAndersen - Those variable names speak for themselves. – Oded Apr 06 '12 at 13:03
  • 1
    @Oded - these might be well-established terms for concepts so no additional explanation is needed if the reader is familiar with the internal ecosystem. For instance everybody at my job knows what a BOKPRT is and what a CDTY is. I maintain my stance that you judge on an incomplete data set. –  Apr 06 '12 at 13:06
  • @ThorbjørnRavnAndersen - If they were established or had specific meaning, the OP wouldn't say they don't make sense (they would if they had domain meaning, which, yes, he would also need to learn). – Oded Apr 06 '12 at 13:14
  • Perhaps we can take this conversation to the chat room? There are too many comments here. – maple_shaft Apr 06 '12 at 13:18
  • @ThorbjørnRavnAndersen The variables have a basic structure, but it is not followed in all the code. These mentioned are database fields, but variables follows similar structure. An example is a var called vCur1 and vCur2 where one is holding customers information and the other, products information. Form names have the same problem (Button1, Button2, Text3, Text4, etc). – Renato Dinhani Apr 06 '12 at 13:24
  • 1
    @RenatoDinhaniConceição sounds like that code was generated by a GUI-tool. –  Apr 06 '12 at 13:55
  • @ThorbjørnRavnAndersen Yes, was generated by the GUI tool, but you always can change the name and add a representative name. – Renato Dinhani Apr 06 '12 at 14:42
  • 1
    @RenatoDinhaniConceição then it sounds like you have a simple refactoring task ahead of you. Good starter tasks for a newbie on the team. –  Apr 06 '12 at 15:38
  • @tp1 There is no real difference between work and play – it's all living. You don't get paid to do shit work, you get paid to add value to the company. Setting the standard that work should be boring and frustrating is wrong, and I advise you to either create a better work environment or move on to a better job. As programmers, we should all be picky about the work we do and who we work with. A rising tide lifts all boats. – Dennis Oct 05 '13 at 05:58
17

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.

Ben Brocka
  • 2,751
  • 1
  • 19
  • 30
  • 4
    "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 05 '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 06 '12 at 14:06
  • 2
    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 06 '12 at 17:35
11
  • 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
jkerian
  • 651
  • 7
    +1 : This is your issue, not the code's :) – aleroot Apr 05 '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 05 '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 Apr 06 '12 at 03:05
  • 3
    @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 06 '12 at 14:09
  • @HLGEM I think most languages have backward compatibility. Is about using the most recent version, not changing the language. – Renato Dinhani Apr 06 '12 at 14:14
  • 1
    @renato, most database applications are not easily backward compatible. – HLGEM Apr 06 '12 at 14:45
11

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.

S.Robins
  • 11,485
  • 3
  • 37
  • 52
  • 2
    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 Apr 16 '12 at 12:46
  • 1
    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 08:33
  • 1
    @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 09: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 09:38
  • 1
    It's also an opportunity to gather content for http://thedailywtf.com – Arkh Jun 12 '12 at 10:23
8

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

hippietrail
  • 263
aleroot
  • 211
  • 1
  • 4
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.

Z. Charles Dziura
  • 739
  • +1 for "ask for help". Working in a team adds costs but also brings benefits. –  Apr 06 '12 at 16:20
7

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.

funkymushroom
  • 599
  • 1
    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 C Wilson Apr 06 '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 07:37
5

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

scott-pascoe
  • 153
4

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.

Scott S
  • 275
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.

Coder
  • 6,968
  • 5
  • 38
  • 49
  • 1
    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
  • 1
    @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 09:05
  • 1
    @Ramhound Legacy code is ok. Writing legacy code today is not ok. – Renato Dinhani 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 Jun 15 '12 at 14:04
  • Update after 6 years: I left that company a few days after posting this question and looking back, it was the best decision I made. I had the opportunity to work in many other projects in other companies and none of them had the same bad practices or lack of quality that I found in that first job. Staying at home learning the current state of the job market allowed me to work in more interesting projects and better companies. – Renato Dinhani Jan 04 '18 at 21:09
  • Glad to hear it - one effective way to rid the world of cr@p code is to refuse to work on/with it. – Grimm The Opiner Jan 05 '18 at 09:32