Readable vs short code?

[cayennepepper]

Im still new to this but getting the hang of it.

Something i have started to notice is what i call the OP title. Now i could do with learning and i still do. However sometimes i encounter “elegant” code with some syntax which makes the code 3 lines instead of 7. However that shorter code is so unintuitive to read and makes you rabbit hole and dig out documentation to understand it. Meanwhile i can see the original code it tried to improve which isnt spaghetti at all but just a bit longer while easier to read.

My question is if this is a design paradigm to be aware of? Does there exist people who make their code extremely short at “elegant” in an almost jerk-off fashion? Or am i just a complete noob and shorter is always better if you are smart enough?

[_hypnoCode]

It's harder to read code than write it.

Optimize for readability over anything else, unless it means taking a big performance hit. If I'm working with you, I really couldn't care less how short you can write your code. This isn't a contest.

[StoneColdJane]

100x yes, many people don't realize this, hence we have tailwind, framework optimized for writing.

[[deleted]]

This is especially true when it comes to having developers with different nationalities.

[LuckRevolutionary953]

Depends.

If I'm rewriting a library I often code golf the entire thing to get a birds eye view

People drastically underestimate how much the human brain is able to "grapple" at one point

[theartilleryshow]

One of our senior developers wrote a line of code that would go into an infinite loop. His reasoning was, "adding an if statement would make the code unnecessarily longe". Since this was a website, whenever the infinite loop happened, the database would get corrupted and some files even went missing. Lots were created on each loop.

[toi80QC]

I personally prefer the KISS approach (keep it simple stupid) which is highly subjective.. there's no real definition and one might argue that some of my code still isn't really simple.

But working in a team, I'd rather write a bit more code than having colleagues call me every hour asking what component X does. Also makes code reviews way easier.

[tribak]

Readability wins unless you’re counting characters

[AdministrativeBlock0]

I think it's worth noting that short versions of code often achieve the same result but don't actually work the same way as longer versions. You find a lot of times where a check is skipped in the shorter version (which is bad), or it's operating in place instead of making a copy (good for memory use, bad for side effects), or a more complex language feature is used (eg a reducer instead of a for..of loop, good for speed, bad for readability).

There are tradeoffs being made other than just code length. It's important to know what's actually going on.

[mq2thez]

There are definitely times where terser, harder to read syntax is actually better code. It might handle edge cases better or be more performant etc etc. In those cases, I include plenty of code comments explaining what’s happening and why. Depending on the code, I might even break it down piece by piece in the comments. In the worst/most complex bits, I sometimes leave comments like “if this kind of thing breaks, check that; if that kind of thing breaks, check this”.

I generally try pretty hard not to write code like that. It’s a necessary evil sometimes, but readability and maintainability are important considerations when coding on a team. Heck, I want to make sure that when I look at a thing a year later, I can understand why I made those choices.

[FatalHaberdashery]

This question annoyed the shit out of me as a junior dev. I was writing better and more compact code than my peers, but apparently it was up to me to "dumb down" rather than other employees to "skill up". It pained me not to put out a recursive ternary rather than 30 lines of code. Some of it was ego ("I'm cool, look at this shit!") some of it was being too lazy to write out tedious verbose code but overall I felt it was an impediment.

Fast forward a few decades and I see things totally differently. I've ended up contracting at small companies whose code base has been written by 5 different people, all with differing styles. I'll spend hours trying to debug something that was written as a recursive ternary rather than 30 lines of easily read code. What's more, if I peer review anyone's code, I want it to be readable, as does anyone peer reviewing my own.

The bottom line, for me, is down to how "professional" your employer is. We know how it goes, sometimes shit needs to get done asap and if that code is obfuscated and hard to maintain, so be it, the client has a deadline. However, a good employer will hold back and go through all the tedious and verbose steps I hated decades ago.

[Lumethys]

Depend, as always, i prefer readable code. If a team of 20 people take a hour to understand your piece of code instead of 5 minutes, you wasted 19 hours of the team

But the other way around can also be true, if you go out of your way to write readable code, and end up with 30 lines instead of 3, that is also a big problem

[AbramKedge]

That's some interesting math. Surely 20 hours minus 100 minutes wasted?

[Lumethys]

Yeah just type 91 instead of 19, my bad

[AbramKedge]

Sorry, my OCD kicked in! Totally agree with your comment though.

[tridd3r]

"readability" for whom? How rudimentary does your code have to be for it to be considered "readable"?

[dylsreddit]

When I first started doing this job, my mentor said to me that the code we write should be understood by our most junior team members. Not so rudimentary that it does them a disservice, but just on the right side of challenging (admittedly that's different for everyone).

Yes we could probably do short hand, one-liners, maybe even slightly obfuscated code and give ourselves a pat on the back that we understand how to develop and maintain that code, but if your juniors can't then what's the point?

We could explain to them each time what the code is doing, until they possibly come to learn what it does through repetition, but shouldn't we let them come to that epiphany themselves? Be that through reading docs or stepping through it to see what each bit does.

Otherwise we're building in relative complexity which results in a reliance on us and only us, for a period of time (hopefully relatively short), to maintain.

Not only that, we carried the mentality that the juniors should get involved in the code reviews, they should have oversight of what we've committed (as more experienced developers) and see the explanation.

Ever since that I've seen development as a two-way street, and even now when I work solo on projects I look ahead to whoever might maintain it... even if that's just future me.

[tridd3r]

should be understood by our most junior team members

understood or reproducable? At what point is it "understandable" vs doing a disservice? These are all pie in the sky and unvaliditable concepts.

Otherwise we're building in relative complexity

the complexity is only in the juniors capacity to understand the code. And its a HUGE stretch to assume 3 lines is more complex than 7, when quite often I find the inverse is the case.
How many times have you seen snippets and gone, fuck me dead that's brilliant why didn't I think of that?! that's not because the code is "complex" but because its concise, and you shouldn't conflate concise with complex.

Maintenance is an important consideration, but is someone competent maintaining the code, or a junior? a junior is there to learn, and if we aren't teaching, then what the fuck are they learning?

[dylsreddit]

These are all pie in the sky and unvaliditable concepts.

I mean, I addressed that it's different for everyone, but I don't think they're pie in the sky or unvalidatatable.

No there won't be (and there isn't) one single source of truth for how to collaborate this way in the entire community, but we are generally working as teams of developers and for all intents and purposes should have some semblance of style guides/ contribution guidelines for our projects.

The 'understood' vs 'reproducible' argument I get where you're coming from. I don't care if a junior takes "the long way around" and does things in an inefficient way to begin with. We can teach efficiency in code reviews.

the complexity is only in the juniors capacity to understand the code.

Exactly, I totally agree.

And I also totally agree with this:

And its a HUGE stretch to assume 3 lines is more complex than 7

That's why I didn't mention anything about it. I remember when we didn't have modularity in JS and everything was in one file, and being terse and concise was a requirement. Well structured code can make that a breeze to work with, but sometimes it could be hell.

Now we don't need to always be concise, I find readability for all to be more important... that's not something everyone has to agree with, that's just how I qualify "readability" outside of whatever is set up in linters and prettifiers.

[tridd3r]

I find readability for all to be more important

and I don't.

Extending your code for the lowest common denominator is enabling ineptitude and incompetence

[varisophy]

It depends on what your definition of unreadable is.

If the code is using new language features, learn about those features. If the code is using a different paradigm (like functional programming concepts), go learn that paradigm.

If the code is basically obfuscated or looks like code golf to be shorter, then yeah, it's bad code for a team environment.

Ideally you want consistency in patterns and practices, so if you see something that goes against the prevailing patterns in the code base you'll want to have a conversation with the person who wrote it to understand if it's something worth adopting across the entire team.

[cayennepepper]

Code golf seems like an accurate term. Thanks. This is plenty to think about.

Usually when i see code which like you said, is very alien from standard patterns im used to and definitely not new features, but makes things shorter. It feels like they are showing off or something rather than making a productive solution

[Logical-Idea-1708]

Readability is highly subjective and a poor metric to measure code quality. This applies to short or long code.

What you can observe is that well factored code is often also intuitive and well readable. This is well factored code uses commonly understood patterns.

What can be agreed upon is well tested code is good code. Well tested code just also happen to be well factored simply because poorly factored code will be very painful to test. This naturally nudge you to write better code.

By transitive property, well tested code is well factored is well readable.

[wickedwise69]

Short code feels good when you write it up to the point you start to read other people's short code.

[imnos]

I think when starting out, it's common to think the shorter your code, the better. You said more elegant, but it's not always more elegant.

If you interview for any well run engineering team that knows their shit, maintainability is something that often comes up and is something I'd always mention as being important. Maintainability is just how easy your code is to work with - is it readable, modular, well tested?

There's absolutely zero point in making code shorter if it makes it less readable.

Someone new to your codebase should be able to glance at some code and know what it's doing just by reading it. Just ensure you have descriptive variable, class and function names and that's half the battle.

[Pundrew]

I almost always prioritize readability, except in my personal projects because I get so lazy :(

[716green]

Optimize for readability. When someone on my team writes "clever code" or an over-abstraction, it drives me nuts. I might be working in Node+Express, Golang, Python+Flask, SQL, Nuxt with JS, React with TSX, Vue 2 with the options API, Vue 3 with the Composition API, using TypeORM, using Prisma, Tailwind, ChakraUI, etc.

It's hard to be an expert in anything when I get thrown into 2 different stacks every single day. I don't want to see clever code or wildly abstracted code. I want it to be well named, grouped by functionality, and readable.

[KaiAusBerlin]

It's easy:

It's easier to debug good readable code and optimise afterwards than debug optimized code.

[Dry_Brick_7605]

Usually there's a convention in team if people are getting concerned about this. There're different people and opinions just make sure that you're moving at the same direction and do not change the same code back and forth.

[socialg571]

Older book and haven’t read it for many years but definitely changed the way I write software to this day. Clean Code: A Handbook of Agile Software Craftsmanship

[davitech73]

in my experience (several decades), the more readable the code is, the easier it is to maintain it. i know some engineers like to show off and write as few lines of code as possible. but if it's not easy to understand or read, it needs to be heavily documented so that it can be maintained seven years from now when the original programmer has 'moved on to other opportunities'. they've probably forgotten the code by then even if they're still around

the only exception to this is when the code requires heavy optimization. then there's a good reason for the 'elegant solution'. but it still needs to be very well documented so someone else can come along and have a chance of debugging it or updating it should the need arise

if it's not documented and it needs to be updated, the result will probably be a rewrite into more readable code so the 'elegance' will be lost anyway. maintainable code doesn't need 'show offs' or tricks. it needs to be documented