readable just means "write it in the way I typically write / understand it in"

which makes it a confusing moving target of whatever the local consensus is... and I don't think these people are self-aware of this fact then just get mad at others for not "getting it" automatically, bah

I think a lot of unreadable is a fairly stationary target however.

Unreadable code is pretty clearly unreadable:

1. by you who wrote it 6 months from now

2. everyone else can't understand what you wrote

This covers a lot of the shit, but is not limited to this:

https://index.dev/blog/...

The current codebases I am using are actually pretty good on naming things. There has not been a whole lot of ambiguity in it. Luckily.

Now, some people are so fucking stupid that they will say readable code is unreadable. Especially when you use not oft features of a language in the current codebase. So some comments on intent can help with them.

I'm pretty sure the idea behind "readable code" is

a) adhering to common language patterns and naming schemes

b) Proper variable and function naming

c) Avoiding god functions that do everything all the time

d) comment whatever cannot be easily understood otherwise, mostly useful for optimization magic and parallelism patterns where the flow is no longer easily understandable

I don't think these are "subjective"... Clearly you can name a function something else than I would, but as long as you name it correctly, and it's short enough so that it's easy to understand, it's going to be readable by me even if your choice of words is difference.

ditto with language patterns. If everyone is using camelCase, don't randomly write with snake case. My eyes will be searching for specific patterns that are common for the language world wide, don't be *that one person* who likes his way better because that's how he does it in TyPEsCrIPt or something.

and so on

Urgh, readability. The thing what python programmers are obsessed about. Doing the easiest language in the world, still spoiling the fun of it to wine about readability. Only a pydev has time left to wine about it.

I started working someday somewhere and the lesson was more that I had to learn to read instead of blaming others. Go slow, go fast.

ai is very good at writing comments and helping you make sense of what the code does

@retoor

I'm sure your post violates a couple PEP entries. Let's run a linter on it XD.

@kiki I always put in my prompt not to write comments. I do not thing that comments add value to clear code.

@retoor Easiest language in the world? You mean C#?

@retoor I do that too

@CoreFusionX you've seen the movie of comedian that said "Someone is gonna PEP8 you!" :P My projects are not linted at all. For the noobs there's black, for pro's there's shed (ironically bit amaturistically written). They format everything, order imports and so on, refactor old string format to the new one.. I hope that the era of linting is soon over, we're wasting time and money.

I wrote perfect pep code for years and couldn't do differently at certain point. Now I don't even know anymore what the linting rules are. Such freedom. Make software fun again.

@CoreFusionX wow, application that I'm working on for almost two months, only line too long issues (I would prefer 120 / 140 limit anyway) and `module level import not at top of file` (thanks for nothing shed, maybe too dangerous to fix?). Well, that was fun to watch. Won't make it part of my development cycle. Hmm, linting era is maybe over. Or should I have used smth else than flake8?

I mean I like autoformat because then you can skim the code easy later, if the format matches the control flow and keywords are highlighted properly in a language

but yeah people too uppity. if the compiler understands it so can you. that's kind of your job

... I don't don't count God objects as syntax related. they're you're bad at architecture and we should probably listen to somebody else related

@retoor does it really bother you that looking at code from Python.org is all consistently formatted? It is nice to not be confronted with different "styles" of code formatting in every single file. I wish there was more consistency in C like languages.

@retoor That sounds ruff ;P

@Demolishun that's a good point. Yeah, C world is total other extreme.

@Demolishun The quoted blog post contains an example of a class that should not be there because it always returns false. Its confusing name: AlwaysNotAvailableAvailability to me it looks like someone wrote that to avoid the "magic number" trap of simply using false in the first place. A comment could have been more "readable", but then again there are software architects strictly against any kind of comment anywhere because proper naming should make the code self-explanatory in theory.

@devux-bookmark or a define or something.