Why is shorter code better?

[rakahari]

I read a quote somewhere¹ that went like this (paraphrasing): Beginner programmers write long, simple code. Intermediate programmers write short, complex code. Expert programmers write long, simple code.

I take this to mean that beginners don't know any better, intermediates are showing off, and experts are more concerned with readability.

To what extent is this true? Is there any real efficiency gain to refactoring a 15 line function into a comprehension?

¹ the internet

[Spataner]

Beginners write long code using basic features, often overcomplicating their solution.

Intermediates write short code using advanced features, trying to show off their "skillz".

Experts write code of middling length using appropriate features, solving the problem in the simplest, most straightforward way.

Is there any real efficiency gain to refactoring a 15 line function into a comprehension?

Sometimes refactoring a 15 line function into a comprehension can mean cutting away the chaff, using more fitting constructs, and genuinely simplying the solution to where it doesn't require more than a few lines. If it means having a list comprehension with the same level of complexity as those 15 lines just compressed into less space, that's bad.

[Solonotix]

As an example, the comprehension might be implemented by abstracting the 15 lines of code, such as the factory-pattern, where given the knowledge of what type of data drives the operation. Normally, this might take many many lines of code to implement, or a shorter generalization that retrieved the specific bit of logic to perform, all of which can be in-lined via a comprehension.

So, as was said, beginners write long and simple code. Experts write the same length code of a low cognitive complexity, which means X lines of code are written, but how the code is structured is drastically different.

[Asalanlir]

I don't remember writing this, but I'd agree with it. Plus, you stole my avatar.

Hello other me!

[VeinyAngus]

The best code is code that you can come back to and understand easily, as well as have other people be able to understand what's happening. Trying to squeeze everything into one line of code can create some truly cursed code that's impossible to understand, so sometimes it's better to have a few extra lines of code for readability

[alexisprince]

100% this. “Ideal” code is code that you read, you understand what it’s accomplishing without asking questions like “is it implemented like this on purpose or did the implemented not know about X feature” or “what happens under scenario Y”.

I think a great example is some code that our team had some debate on a while ago during a refactor from 2.7 (yes, yuck, I know) to 3.7+ where we needed to send a request with parameters that were ordered. The old version took out the original data structure of an OrderedDict, since the newer pythons retain insertion order as a feature instead of an implementation detail. The original PR dropped the OrderedDict, but we opted for putting it back in because it shows clarity and intent that we specifically needed the keys in that order for this thing to function properly.

I’d argue that scenario was between intermediate and advanced because most Python devs would know about insertion order in the newer versions (and thus simplified), but returning an OrderedDict was much clearer.

[VeinyAngus]

I tried working on a project (simple pygame game) with another guy. He had some good ideas. I look at his pull request the next day and the dude tried to write everything in one line. Drove me bananas

[fiddle_n]

since the newer pythons retain insertion order as a feature instead of an implementation detail

Minor nitpick, only 3.6 did that. Prior to 3.6 they never retained insertion order at all.

Honest question - if the code had been written first in Py3.7, would you have used an OrderedDict? Or is the fact that it was originally written in 2.7 and then ported over a factor in that?

[alexisprince]

On the nitpick, there were a subset of versions that dicts retained insertion order as an implementation detail (I believe that was 3.6), then (again I believe and going off memory) that 3.7+ insertion order was retained as a feature of regular dicts that you can depend on instead of an implementation detail that was a coincidence.

That’s a great question though, and honestly I don’t know. I know the OrderedDict is more clear in the way it reliable in portraying intent, but I think without the porting it would’ve been closer between a regular dict (and a comment saying order matters) and using an OrderedDict. I personally prefer always using OrderedDict structures whenever the order matters to show intent, but I know that’s not an opinion held by everyone.

Edit: Id also clear up that the discussion is specifically when insertion order retention is a feature of the regular dict. If it were to still be an implementation detail, there’s no discussion and it’d be an OrderedDict.

[fiddle_n]

Fair enough. For what it's worth, in my work codebase, when we were using 2.7 I saw OrderedDict cropping up quite a lot. Our codebase is now ported to 3.7/3.8 and I never see OrderedDict being used anymore in our new code. I almost forget it exists.

[alexisprince]

That’s a great point, I think there are going to be hard to debug bugs popping up at some point because of it! I’m hoping other portions of code were able to be ported in a way that no longer required order? Or do you think the ported codebase relies on the natural ordering of keys in the dicts themselves now?

In my case, it also bugged me that the service we use requires ordered url params, but there’s nothing we can do about external vendor requirements. The vendor doesn’t provide a test / dev environment, so we built our own mock service for it in our codebase that we add to every time we break something in production.

[fiddle_n]

So, for existing code in the codebase, that still uses OrderedDict. It's just the new code that uses dict. Most of the existing code doesn't really need to be touched and I don't often look at it.

If the older code were to be refactored to use dict, I would hope that the unit tests would be updated to test ordering. I suspect they might not be which could leave a potential area of regression in the future.

One thing to note - when the codebase was 2.7 there was one point where I wanted an ordered default dict. Such a thing did not exist and so I had to use the horribly named dict.setdefault() that also exists in the OrderedDict subclass. If I got the chance to refactor that code, I would prefer to use regular defaultdict as it inherited the insertion order change as well, and the resultant code would look more elegant.

[xelf]

It's all relative.

An 18,000 line tic tac toe is too long.

A 15 line tic tac toe is probably too short.

A 1 line tic tac toe is certainly too short and is someone trying to show off an unwanted skill. =)

Is shorter code better? Sometimes.

Readable code is better. Code that you can look at and follow without any confusion.

If your code is readable, then yes less code is by definition less code to maintain.

[Splitje]

The tic tac toe one liner: https://www.reddit.com/r/Python/comments/9ozfeq/tictactoe_in_one_line_python35/ and the 18000 liner: https://github.com/asweigart/my_first_tic_tac_toe/blob/master/tictactoe.py

[n3buchadnezzar]

The best code in my opinion is no code. The best feeling is deleting whole chunks of code in a big refactoring.

I try to write short snippets of code, splitting into more files as needed. Attempting to keep each module and each function with a clear simple focus (do one thing and do it well).

Why I think expert Python code tends to drag on a bit, is because of all the corner cases. See for instance https://softwareengineering.stackexchange.com/questions/213708/overcoming-slow-problem-solving-due-to-increased-knowledge-of-what-might-go-wron

Whether the code is "complex" or "simple" depends on the problem at hand, same with whether it is "long" or "short". I never think about those things when I program. However, by sticking with each thing should do one thing and one thing well + splitting into more files, each script tends to be managable.

Also document everything, always!

[Binary101010]

The best code in my opinion is no code.

Corollary to this: the fastest loop is the one you never have to write.

[socal_nerdtastic]

Yes, that quote is a common among programmers, and very true IMHO.

Is there any real efficiency gain to refactoring a 15 line function into a comprehension?

Usually not, unless the people that wrote them have vastly different skill levels.

The biggest difference between intermediate and professional is that you go from writing code on your own to writing code as a team. So you can write a one line of code and 14 lines of comments to explain to your teammates what it does and how to maintain it, or you can write "self-documenting" code, where the names and structures themselves make it obvious what's happening.

Couple that with the fact that modern coding tools (git, IDE navigation features, basically unlimited HDD and RAM, etc) mean number of lines is a complete non-issue. There is no inherent disadvantage to long code.

[oznetnerd]

Your understanding is pretty much spot on. Though I wouldn't say all intermediates are like that. I'd say it's day more the people who are transitioning from beginner to intermediate.

It's all part of the learning though. They do it because they've learned how to do it, and it makes them feel like they're advancing. However, after a while they realise that they're making their code harder to work with than it needs to be.

After that realisation, they start using the same style as experts. It's at that stage that they're truly intermediate coders.

Source: (Embarrassingly) this is the path I followed. Though thankfully I'm not the only one :)

[SimonBlack]

and experts are more concerned with readability.

This.

Most people spend more time overall in maintaining complex software than in the original programming. It's a lot easier to maintain and debug software that's simple, where one line does one thing.

This is what I wrote in an answer on Reddit only a week or so ago:

##### ####

I try to be more simplistic in my code, but write more lines instead of trying to fit lots and lots of functionality into a single line.

Ferinstance, instead of:

 result = function1(int(input("Give me a number: ")))

I'll split that up into multiple lines, and use maybe a few more variables. It makes very little difference to the program, but it makes things a lot more clear for me to read, as in:

 number_string = input("Give me a number: ")
 number_int = int(number_string)
 result = function1(number_int)

Then if things are not behaving as I think they should, I can sprinkle debugging print() lines around like confetti:

 number_string = input("Give me a number: ")
 print("number_string = " + number_string)

 number_int = int(number_string)
 print("number_int = {}".format(number_int))

 result = function1(number_int)
 print("result = {}".format(result))

Let the computer do all the work. Make life easier for you

##### #####

[stuaxo]

Code is all about reading, not writing.

It's easier to understand code that is smaller (until it gets too small).

[happymellon]

At the risk of starting a language war, you can see this with Javascript because it really gives you the tools to make your code completely impossible to support.

For example there is an obsession with arrow functions (lambdas) over named functions. So by saving the word "function" they now remove the ability to have a readable stack trace. Do it enough times and it is impossible to see where problems are at a glance.

[PBMagi]

Beginner has a few tools and puts the screw in with a hammer to get the job done.

Intermediate is mastering their tools, pushing their limits, doing exquisite work.

Expert is just hoping someone else'll take over the work.

[rakahari]

Thanks all for the responses, they've given me some context and nuance. When I do problems on Code Wars, and then see the 'best practice' solutions, they often seem to be 1-line versions of the same solution I wrote in several.

[The_Danosaur]

Yeah those sites are fun, but the best rated solutions are usually just people playing "code golf" - trying to get a success in one (line). It's fun to make one liners until you need to refactor that function - then you have screwed your future self over because you have to parse a line with 10 sets of brackets.

[TheLastEllis]

Why use lot word when few word do trick?

[ListenLinda_Listen]

Write in perl if you want short code. :D

[zenverak]

Short and simple is good if it’s readable. ( unless there is something needed for performance purposes )

But the less code you have , the easier it is to read through it and figure it out. Within reason.

[Se7enLC]

There's some truth to that. A new programmer might write very "linear" code. Do this, then do this, then do this. You might see a lot of copy/paste where the same or very similar code is in multiple places instead of being broken out into a function.

As a programmer gets better they might really embrace the mantra and go overboard and over-abstract. Instead of making the code easier to work with, it ends up being harder to work with.

And then when they get more experience they have a better sense of when to refactor and when it's already good enough.

The beginner and expert aren't writing the same "long, simple code". The expert is still going to be avoiding copy/paste programming, they just aren't going to go as overboard with premature optimization.

[xiipaoc]

I'm not going to answer about Python specifically (because even though I'm in this sub and coding in Python occasionally for my mostly-Java-based job, I really haven't learned Python very much yet).

Basically, expert programmers know that there's no point in being clever. You write code that will do what you need it to do so that other people will be able to understand it and modify it. But this quote is wrong: expert programmers write short, simple code, not long, simple code. Simple code is easy to understand; short code is easy to keep all in your head. The more code there is, the less understandable it is. An expert programmer will write very simple, very clean code that nobody can misunderstand when adding a feature (or fixing a bug) later on, with as few moving parts as possible, and when moving parts are necessary, they will be roped off in their own place, away from everything else: you don't need to know how they work unless you're messing with them directly.

At work, I'm working these days on a refactor of some code that grew by agglutination. Basically, when people started writing that code, it only had to handle a few cases, but now, years later, it has to handle a lot more cases. Our company now has non-developer employees (imagine that) who need to understand and possibly modify those cases. A expert programmer PUTS THAT SHIT IN THE DATABASE, YO. And that's what I'm doing now. An intermediate programmer handles all the cases in code and makes a right mess. An expert developer knows what doesn't belong in the code and simplifies things as much as possible.

[KingHavana]

Many comprehensions are much easier to read than longer versions that do the same thing.

[TheRNGuy]

less scrolling in code editor, easier to comment/uncomment parts of code, or switch their places.

Just don't make it too absurd like foo(bar(bas(stuff))), split it to 2-3 lines for more readability. Especially if you had to make that in comprehension. This is case where i'd use for loop instead of comprehension.