@m3tti

Even though i think most people like if code looks more technical than actually explaining what it does.

There's definitely a balance here. Some people seem to think any "symbols" (characters other than alphanumerics and maybe ()[],) instantly make code unreadable and all identifiers should be (English) words.

I disagree. Instead of, say, "the area of the square whose side is the hypotenuse is equal to the sum of the areas of the squares on the other two sides" or "it is impossible to separate a cube into two cubes, or a fourth power into two fourth powers, or in general, any power higher than the second, into two like powers" I strongly prefer these formulations:

• a² + b² = c²
• ∀a,b,c,n ∈ ℕ, n > 2: aⁿ + bⁿ ≠ cⁿ

Here the "more technical" looking version also explains better to me what it's doing. But of course it is possible to go too far and get lost in a sea of obscure symbols, as well. Anyway, my point is that more technical can also mean more readable.

Sorry for the tangent.

@barubary ok thats right for calculations and everything math that makes total sense due to the fact that its a language on their own which is more narrow and compact to describe your problem space. But i was focusing on stuff like managing users and doing iterations and stuff like that. "Business Logic" as people might call it.

But i totaly get your point my point was just for stuff that describes the flow of the programm.

{<br>  "lastName": "Smith",<br>  "firstName": "John",<br>  "age": 25<br>}<br>

@m3tti

"Business Logic" as people might call it.

Heh. We might describe it using some sort of Common Business-Oriented Language and make it very readable and English-like. 😈

@barubary
mhhh

Somehow it doesn't work for me.
norden.social/@leobm/115688763…