I don’t agree with these opinionated defaults, but I’m primarily a Ruby programmer so my tolerance for expressive code is higher. As long as the linter is configurable I don’t really care.
New Ways to Be Told That Your Python Code Is Bad
201–210 of 262 posts
Re: New Ways to Be Told That Your Python Code Is Bad
#202Earlier quoted context omitted.
If you don't like awkward ugly clunky syntax, you probably shouldn't program in Python. And, for that matter, if you like correctness checking, you also shouldn't program in Python...
Serious question, what alternative(s) to Python would you recommend with nicer syntax?
Ruby for me. I program in both, primarily Ruby with a few python microservices and Ruby’s syntax is similar to Python in a lot of cases but much easier and nicer to break out for something “nicer” to look at. All in my opinion of course.
Re: New Ways to Be Told That Your Python Code Is Bad
#203> Python programmers in general have an irrational aversion to if-expressions, a.k.a. the “ternary” operator. Because the Python ternary operator is fucking backwards! Why on earth would you put the condition in the middle !? x = 4 if condition() else 5 vs.: condition() ? 4 : 5 vs. the author's own lisp example: (setq x (if (condition) 4 5)) I love ternary operators, and Lisp/ML-style if else blocks that return thing…
I prefer perl's style, which IIRC is also in ruby and coffeescript: x = 5 x = 4 if condition()
Ruby also has a C-like ternary operator. Many options for people that prefer them :)
Re: New Ways to Be Told That Your Python Code Is Bad
#204Earlier quoted context omitted.
I love the Python version, it reads like English. Use umbrella if raining, else wear shades.
Is this how you would say it in English though? I think "If raining use umbrella else wear shades" is closer to regular English.
It's closer to Python too, other guy messed up the example
Re: New Ways to Be Told That Your Python Code Is Bad
#205I always had the vague impression that the original purpose of linters was for some arrogant ahole to impose his "style" on other people. Now I have confirmed this impression.
Re: New Ways to Be Told That Your Python Code Is Bad
#206A lot of bloggers love linters, and they will look for any reason to promote them. They will say things like “programmers don’t like to have their code criticized” and “chicken-little reaction” and other excuses. But fundamentally the problem is that bloggers like to tell others what to do.
Well, tough shit, because I closed the tab.
Re: New Ways to Be Told That Your Python Code Is Bad
#207Linters are good because they stop people arguing. Some early employee in the team defines some set of rules, and that's just the way things are from then onwards. Less time bickering means more time spent doing actual productive stuff.
Linters are bad because they force your code into unnatural shapes, preventing you from exposing visual patterns and harming code comprehension, and also regularly harming diff sizes. (Both of these statements can be true.)
True. Both can be true! :-p
Re: New Ways to Be Told That Your Python Code Is Bad
#208Earlier quoted context omitted.
Hating linters is like hating a weight scale for telling you your weight, or hating a blood exam for telling you that you have high cholesterol. If the linter says your function is too long then you refactor it, you don't turn off the linter. You also fix it immediately, not "later" (broken windows theory) before the next offender copies and pastes the offending code or continues making it worse. In underdeveloped co…
Linters tell you when your code doesn't respect certain rules. That's it. These rules may or may not lead to better programming, that depends on the rules themselves. I could build a linter that forbids all variable names longer than three characters. Would that make the code good? I doubt it. Sometimes the extra weight you notice on the scale is just muscle, and there's nothing to worry about.
That's a straw man argument.
Re: New Ways to Be Told That Your Python Code Is Bad
#209> Anyway, this is just a style thing. It doesn’t affect program correctness or structure in a meaningful way. The nice thing about ternaries is that they're expressions, so they don't "infect" our code like statements (e.g. 'if'). For example: if xCond: x = x1 else: x = x2 if yCond: y = y1 else: y = y2 if zCond: z = z1 else: z = z2 foo(x, y, z) This lint rule will tell us to do the following instead: x = x1 if xCond…
I think I might be in the minority here that I prefer the fully laid out statements. Sure in small cases this small ternary use is great! However too many times I've seen people chain them for far too many characters just to be "on one line". We don't use one letter variable names anymore, so in the same reasoning why should we do the same to our code?
I personally would have wrote the first one as a first pass, mostly so I could probably at some point put break points on what is going on. Then probably called it 'done'. I had actually forgot you could even do this thing in python. The highest complement I get from other programmers is 'your code is easy to read'.
Everyone has their own 'style' they like. It is usually not that big of a deal. It becomes a big deal if you get someone on the team who becomes obsessed with it, or someone who is always sloppy. Compact styles tend to be harder to decipher than simple ones. As when you are reading them they usually are not the same style context as all the other code around it. So it causes your brain to have to stop and figure it out. With python sometimes those compact styles actually run faster, so they can be handy to know about (test it though).
In java there is this thing where many will do things like blah = x().y().z(); Yet at any point in that chain something could crash out and return a null. It is compact for sure. But really is a pain to debug, but easy to read. Yet a lot of what is going on is burred in the 'middle' what if something in the middle is returning the wrong thing and the next thing in the chain happens to have the right method?
Compact styles can be easy to read sometimes if you know what that style is. You can also very easily introduce very subtle bugs. You can also convey the wrong meaning to the next poor soul that has to look at your code 3 years from now, 2 years after you left the company.
I use this style as sparingly as possible and fall towards verbose and spaced out code. I try to make it easy to read and broken down as best as possible. 6 months from now my tired brain will thank me.
For something like this example if I ended up with an if tree like that I would look at the underlying data structures. There is a data problem here and there probably would be a better way to do it.
Re: New Ways to Be Told That Your Python Code Is Bad
#210A lot of bloggers love linters, and they will look for any reason to promote them. They will say things like “programmers don’t like to have their code criticized” and “chicken-little reaction” and other excuses. But fundamentally the problem is that bloggers like to tell others what to do. Well, tough shit, because I closed the tab.
Those who can, do. Those who can't, teach. Those who can't teach, write blog posts.