Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It's all Greek to me: Thoughts on code readability and aesthetics

avraam.dev

Post reply on HN
Print view View original

51–60 of 63 posts

Re: It's all Greek to me: Thoughts on code readability and aesthetics

#51

Post by slx26 »

davnicwil wrote: post #30
slx26 wrote: post #18

Earlier quoted context omitted.

I read your comment too fast and I almost dismissed it, thinking you were talking, like everyone else, about formatters (gofmt, rustfmt). But what you are saying is much more interesting, as we are all allowed to keep our preferences. Is there any major editor/IDE working on this? You are making me miserable, now that I read this I can't live with just formatters anymore :D

So, this is indeed a very cool idea, the fundamental issue you'd have though is that you can't abstract away from the 'ground truth' formatting at the source control level. You could even sort of brute force this without IDE support by reformatting everything to your preference on git pull and back to ground truth on git stage/push, but when it comes to diffs, merges, etc, you must work in terms of the ground truth f…

I can definitely see it might have quite a few problems. Forest [0] and others even attempt to abstract on syntax, which I generally disagree with as it becomes a problem to learn the language or get help / discuss some things with other people, especially online.

I'm not dismissing the default formatter, it's obvious you still need one canonical representation of the code, but I don't think you should view it as "hiding" the formatting. In my view, it's more like opening a web page with one browser or another, or with one device or another. It always looks a bit different. Or maybe I have a theme configured on my main browser or whatever. I like to have my preferences, but if I have to look at the page from another browser, it's not a big deal either. The extra configuration might not be worth it or slightly inconvenient in some cases, but I doubt it's counter productive. The same way as I might prefer to read/write with a certain font or use this or that color palette.

Maybe the takeaway is that code is more personal for some people than we like to generally admit. You are talking in a language and you want to be able to express yourself as comfortably as possible. I mean, we have had turing-complete and even "productive/decently ergonomic" languages for a while, and yet a lot of people keeps coming up with new languages, because they are much more than just a tool to get things working. We want to express ourselves as we "think", and formatting may be a small part of that, but it's still a part of it.

[0] https://github.com/forest-lang/forest-compiler

Re: It's all Greek to me: Thoughts on code readability and aesthetics

#52

Post by strokirk »

Rainymood wrote: post #3

>Next time we have a conflict with a colleague on what is “readable”, let’s ask ourselves “Am I talking about understandability or I am talking about aesthetics?” This is why I'm in favor of auto-formatters like Black for Python. Nobody really likes it, but nobody really hates it either and you get used to it. What this does is that it completely removes the style component of the discussion, leading to better and mo…

Oh, there are many that hate it, we just get voted down fairly fast.

Re: It's all Greek to me: Thoughts on code readability and aesthetics

#53

Post by celticmusic »

empath75 wrote: post #45
fouc wrote: post #40

Earlier quoted context omitted.

It's hard to explain to junior engineers why chasing fads is a bad idea. Why boring technology is often the best choice. That's only something that most people figure out with experience.

Seniors often don’t like doing new things for the simple reason that they already know how to do things a different way and they don’t feel like learning something new.

and juniors like to make mistakes because that's how they turn into seniors.

The point is, and will continue to be, that a senior's opinion should be heeded or you disallow them from steering the ship away from the glacier that they know is there.

You can always justify everything with a reason. If your goal is to justify, then great, you did that. If your goal is to be effective, you need to stop trying to justify.

Re: It's all Greek to me: Thoughts on code readability and aesthetics

#54

Post by davnicwil »

slx26 wrote: post #51
davnicwil wrote: post #30

Earlier quoted context omitted.

So, this is indeed a very cool idea, the fundamental issue you'd have though is that you can't abstract away from the 'ground truth' formatting at the source control level. You could even sort of brute force this without IDE support by reformatting everything to your preference on git pull and back to ground truth on git stage/push, but when it comes to diffs, merges, etc, you must work in terms of the ground truth f…

I can definitely see it might have quite a few problems. Forest [0] and others even attempt to abstract on syntax, which I generally disagree with as it becomes a problem to learn the language or get help / discuss some things with other people, especially online. I'm not dismissing the default formatter, it's obvious you still need one canonical representation of the code, but I don't think you should view it as "hi…

I definitely agree with most of this but I have to challenge the web browser analogy because that's a scenario where the concept of the view (visual, screen reader, etc) being interpreted from the textual representation is built in - as in, there is no end user who consumes the raw markup as-is. So different end users working with different views is a completey natural and expected thing.

I guess that's what's missing to make this work for code. The raw code is intended as the final representation to the end user.

Maybe what you'd need to make this work is to build in the concept of formatting to the source control itself, so all the way through the tooling you could 'render' the code as you'd like to see it, and do all operations on it using that view (including diffs, etc). Maybe sort of like you can with syntax highlighting, except with positional formatting instead.

Re: It's all Greek to me: Thoughts on code readability and aesthetics

#55

Post by dredmorbius »

dalai wrote: post #48
twic wrote: post #42

Earlier quoted context omitted.

A comma separates clauses that make grammatical sense on their own, or at least where one of them does. So "In Greece, we have a similar phrase" is fine, because "we have a similar phrase" is complete in itself. Whereas "Readable code, is a piece of code" is not correct, because "is a piece of code" is not complete - it's missing a subject. Likewise, "In Germany, they say" and "In 16th century, in the Habsburgermonar…

I am Greek and we don't use that many commas. Definitely not in this way. I think the Greek language is also not as flexible with comma placement as perhaps English is. What I've noticed is that some people never learned how to use them. They just write a sentence (or a whole essay) and generously sprinkle some commas afterwards, normally wherever they would make a short pause. I've seen this with colleagues from Ger…

Russia and the US

AP style, or Oxford and a subtle political commentary? ;-)

Re: It's all Greek to me: Thoughts on code readability and aesthetics

#56

Post by Avamander »

makapuf wrote: post #43
stereolambda wrote: post #8

Earlier quoted context omitted.

I'd say the main reason for strict formatting is the organizational one: when you really need for the same file to be edited by many people and not turn into a mess. Otherwise, it may be convenience, as I don't have to maintain consistency manually. May be, because in languages where there are multiple syntactic ways to do things (Python, JS), I want flexibility in emphasizing things. (Even if I don't overuse it.) It…

languages where there are multiple syntactic ways to do things Python zen says: the should be one (and preferably only one) obvious way to do it. Perl might fit your description better.

Unfortunately we have many ways to do format strings now :P

Re: It's all Greek to me: Thoughts on code readability and aesthetics

#57

Post by kinkrtyavimoodh »

As far as linting and formatting is concerned, having a company-wide policy and having IDEs implement it automatically and presubmit checks enforce it is enough.

However a lot of the arguments over code review come from (sometimes) aesthetic preferences about code decisions. Should this be pulled out as a function? What should it be named? Should this be inlined or pulled out as a variable? Is ~A or ~B more readable or ~(A and B) (the latter ends up causing the ugly sandwich (!( in languages like C++ or Java), etc etc.

These don't have automated solutions, but can nevertheless spark impassioned arguments.

Re: It's all Greek to me: Thoughts on code readability and aesthetics

#58

Post by makapuf »

Avamander wrote: post #56
makapuf wrote: post #43

Earlier quoted context omitted.

languages where there are multiple syntactic ways to do things Python zen says: the should be one (and preferably only one) obvious way to do it. Perl might fit your description better.

Unfortunately we have many ways to do format strings now :P

No, we only have fstrings now :) - I know -too well- backwards compatibility...

Re: It's all Greek to me: Thoughts on code readability and aesthetics

#59

Post by EForEndeavour »

Avamander wrote: post #56
makapuf wrote: post #43

Earlier quoted context omitted.

languages where there are multiple syntactic ways to do things Python zen says: the should be one (and preferably only one) obvious way to do it. Perl might fit your description better.

Unfortunately we have many ways to do format strings now :P

list(map(f, iterable)) versus [f(x) for x in iterable] also comes to mind!

Re: It's all Greek to me: Thoughts on code readability and aesthetics

#60

Post by makapuf »

EForEndeavour wrote: post #59
Avamander wrote: post #56

Earlier quoted context omitted.

Unfortunately we have many ways to do format strings now :P

list(map(f, iterable)) versus [f(x) for x in iterable] also comes to mind!

If I remember correctly, it is recommended to use list comprehension (see stackoverflow)
Post reply on HN