3

I've been working on a Python(Django)/JavaScript(AngularJS) based application for some time now.(I learnt all of these on the way, had previously been a Java only programmer)and have hit moments where the code was really unmanageable:

Single js script for the entire application, around two-dozen controllers, a dozen or so services and other components, all squashed into a single file.

I refactored that successfully, though, added a Grunt for minification and proper generation of final code for the application, shifted to bower for package management and in turn basically made my life easier.

Only if I had optimised things earlier in the development cycle, things would've been easier. So one thing that I've been wondering is what would be the right time to optimize my code? Weekly..Biweekly or just when and how do I assess code quality everyday, everytime I run a build.

There's probably a lot of tools out there for what I want to do, but what I want to know is where I should get started with this and what is the right way to optimize source code to use good programming standards, given that Python and JS are statically typed languages, with no particular coding standards enforced by default, as compared to Java, where I found it easier to write good code.

  • I already read it while searching for a similar question. My question is focused specifically at ways to optimise python and javascript code, and what would be good programming constructs in these languages? – Divij Sehgal Jul 11 '17 at 12:37
  • I'm unclear on this - is this a question about optimization or about avoiding technical debt? – Dan Pichelman Jul 11 '17 at 13:02
  • @DocBrown I re-read and you are right, this isn't a duplicate (not retracting close vote though because question looks unclear to me anyway) – gnat Jul 11 '17 at 14:51
  • 2
    Possible duplicate of When to refactor. @gnat: don't mind, I found one. – Doc Brown Jul 11 '17 at 15:02
  • 2
    @DocBrown Well, we do have Code Reflection, CodeMirror and Code Lens, so... I guess we can keep going on Source Code Optics and add Code Refraction to it, too. – T. Sar - Reinstate Monica Jul 11 '17 at 19:41
13

First of all, no Java does not have enforced coding standards. Anything you can make work in JavaScript I can also make work but look worse in Java. Working, in any language, doesn't ensure that it's well written. Need proof? See Code Golf.

Coding standards exist in you. Not the language. You're likely feeling this way because you've looked at enough Java code at this point you have an expectation of how Java code should look. You haven't developed that sense in your new languages yet.

Important to understand is that up-to-coding-standards is NOT the same as optimized. Optimized is about not wasting memory or CPU cycles. Up-to-coding-standards is about not wasting programmer time with hard to read code.

The best "tool" for this is a fellow programmer who can look at your code and tell you how easy it is to read. We call this a code review. If you're not doing it every time you write new code you are making things difficult for anyone that wants to work with the code later. Including you.


When to refactor?

One of the best times to refactor is just before adding a new feature.

Before you have an actual feature in mind you have no idea how to code is going to need to change. It's tempting to over generalize. Flexible code is good but unfortunately sometimes we attempt flexibility by imagining how it will change and accommodating imagined change. This creates needless code, needless abstraction, and needless indirection. The result isn't flexible.

However, you should expect that the code will need to change. The key is to minimize the assumptions you make about the future. Assumptions you must make should be isolated from each other. Make decisions in one place so that change can occur in one place.

When you have an actual feature in mind you can refactor to create a good place for this feature. For example, this is a good time for a class name with the suffix Impl to get a real name that differentiates it from the new implementation class you're about to add.

So, yes, right after a test passes is a time you could do a refactoring. Just be sure you know why you're refactoring.

  • "Up-to-coding-standards is about not wasting programmer time with hard to read code.": That's the ideal, and if the coding standard is good and has the neccessary flexibility it tends to be a reasonable match. Many are too old, too rigid, for very different environments, or are tragially misguided though. – Deduplicator Jul 11 '17 at 13:01
  • 3
    @Deduplicator which is why the best enforcer of coding standards isn't a tool or a piece of paper. It's a fellow coder that believes they might have to actually work with what you're writing some day. – candied_orange Jul 11 '17 at 14:21
  • 1
    Yes, pragmatic self-interest can do wonders. – Deduplicator Jul 11 '17 at 15:23
  • @CandiedOrange What I really meant about coding standards was that since I was pretty used to Java and (as you later mentioned) I have not become so comfortable working in Python/JS. And about the fellow programmer part: I am working among a couple infrastructure people who don't really write code, and I don't remember many of my friends working on a similar stack so I cannot ask them for suggestions. Best Case: I could put it up on github, but it is proprietary code, so I guess I am pretty much on my own.(funny)The fellow coder who'll work with my code is himself a network/infra person. – Divij Sehgal Jul 11 '17 at 15:33
  • 1
    @TimothyTruckle As a matter of fact I am going to PyData Delhi next Saturday. – Divij Sehgal Jul 12 '17 at 5:02
4

From your question, it appears your are confusing "refactored" with "optimised" and are actually referring to the former.

When should you refactor? That's easy, straight after (never before) your previously failing test "goes green". If you aren't using TDD though (and if not, why not?), then there's rarely an ideal time to safely refactor as you might break something in doing so. It becomes a case of "refactor at your own risk". The only real rule then is "the longer you leave it, the greater the chance of breaking things when you do refactor".

  • 1
    As a matter of fact, that is what I meant. TDD is next on my list. I recently got my second internship(I wrote real code here, more like learning basic stuff on the previous one), where I learned python and js and more focus was on learning how things are working, than writing tests or refractoring code(tdd is a must now) and at your own risk is what had been going on for a while now, which is why I asked this question. This answer sums up what I had in mind about TDD. Thanks :) – Divij Sehgal Jul 11 '17 at 15:41
  • 1
    You are welcome. Also, I'm please to see you changed your mind and opted for @CandiedOrange's answer as the accepted one instead of this one. Mr Orange's answer is a better fit here than mine. I only added this as I wanted to emphasise the risks of refactoring without tests. – David Arno Jul 11 '17 at 15:55
  • 2
    Mr Orange? Sheesh. Even my father isn't Mr Orange :) Anyway, I completely agree with ever word here (even the punctuation) and find it so appropriate it inspired me to edit my answer. So why wouldn't I give you a +1? – candied_orange Jul 11 '17 at 16:10
  • 1
    I plus oned both your answers, not knowing I could only mark a single one as an accepted answer. Both your answers are written with a slightly different point of view and are both individually valid. – Divij Sehgal Jul 11 '17 at 16:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.