14

I graduated from university about five months ago, and have been working in a local startup for past four months. While at university, I studied Haskell, F# etc on my own. We were taught Java at the university, but I was exposed to functional programming very soon, and have spent far more time with it than I did with imperative programming. As a result, my brain is wired for a functional thinking. The company I have joined uses Python, and the code is heavily imperative. I am having a very hard time reading imperative code. I cannot keep a track of mutations. When an for-if-else-for-... nesting goes more than four levels deep, I completely lose the track of what's happening in the code. To add to it, Python is a dynamic language, so there are no types in the code. It's been weeks since I have been trying to understand a part of our codebase (which is supposedly 'moderately complex'), but I haven't made any appreciable progress so far in understanding it. Please offer me some practical techniques on how I should go about understanding that code. Thanks in advance!

Edit:
Maybe I should also mention that there aren't really many comments in the code, and the names are also not very intuitive.

an0nym0us c0ward
  • 141
  • 2
  • 1
    Would you rather have no comments or inaccurate comments? I'm sure comments wouldn't age well under the conditions you mention. – Larry Coleman Sep 27 '11 at 20:23
  • Unless the code is in that extremely small subset of code that can be attributed as "self-commenting," I would rather have at least some comments, which might at least include a number of helpful hints to guide me through otherwise indecipherable gibberish! But that's just me! – John Tobler Sep 27 '11 at 23:05
  • 2
    Even imperative programmers tend to limit their side-effects, at least intuitively, and write small methods. I think you just landed on a less-than-ideal codebase. – Mauricio Scheffer Dec 06 '11 at 18:55

5 Answers5

14

Understanding legacy code is hard. It has almost nothing to do with functional vs. procedural.

  1. Create a map of some kind. A component diagram of the Python packages and modules. For each module, you'll need to create class diagrams.

  2. Use the Python interpreter. You should be able to import modules, create objects and exercise them interactively. That's why Python is popular. You can print type(x) to see what type a variable (x) actually is.

  3. When in doubt, be sure to read the unit test code. If there is no unit test code, you have large, looming problems in addition to learning a new code base.

  4. Write stuff down. Start with side documents. Then, when you think you know what's going on, add docstring comments to functions, methods and classes. Add these early and often.

  5. Use Sphinx with 'autodoc' to collect what you're learning.

The most important part is this. It's hard to keep things in your head. It's easier to keep things on documentation files.

S.Lott
  • 45,264
  • 6
  • 90
  • 154
12

I am having a very hard time reading imperative code. When an for-if-else-for-... nesting goes more than four levels deep, I completely lose the track of what's happening in the code.

Wait...anyone completely looses track of the code with such deep nesting levels. Or as Linus Torvalds put it:

If you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.

Maybe I should also mention that there aren't really many comments in the code, and the names are also not very intuitive.

This does not sound as if your company is adhering to common best practices.

If I were you, I'd just try to understand the code base by discipline and force. Just dig into it, again and again and again. It's probably like anything. Right now you feel like you're underwater and can't breathe but continue to examine the codebase and soon you'll swim to the surface.

I'm afraid your question lacks the technical details to offer you a good advice on how to understand the codebase, but it's never wrong to go through it with experienced colleagues in a few sessions. Let them explain you the overall architecture and how the different components interact with each other, alongside with implementation decisions they made.

It's hard to give general advice for the transition from functional languages to imperative/OO ones. Sure, I could mention a few flowery phrases like "You need to think about states and behaviours of objects", but these won't help you much, I think this is something you have to experience.

Falcon
  • 19,248
  • 4
  • 78
  • 93
  • The indentation problem can be worse: when the language is columnar code (like RPG), and there _isn't_ any actual indentation. Some tools attempt to fix this... – Clockwork-Muse Sep 27 '11 at 16:09
2

If (big if from the bad practices you describe) there are unit tests, then you can look at those to see how the code is tested. This can offer a good insight as to what the code does.

Otherwise, I would suggest reading more generic python code to get used to the way it is written.

Sardathrion - against SE abuse
  • 3,706
  • 3
  • 19
  • 34
2

You might try translating some fragments from Python into pseudo-Haskell or whatever you like. That can give you a sense for what imperative constructions loosely map into what functional constructions. As you get more experience the imperative constructions will start to feel more native.

I went from programming OCaml and Haskell to programming Java and Python, and my experience is that imperative programming is not as big a leap as dynamic typing, which to this day feels alien.

Robert Tupelo-Schneck
  • 121
  • 3
1

I suggest you put breakpoints and start using the Next command (as if you're debugging), this will help you understand the flow (probably on branches, there are paths which are more likely to be taken, on those you should concentrate to get the general idea of the code).

(I had good results with Eclipse along with PyDev as Eclipse plugin)

Liran Orevi
  • 206
  • 1
  • 4