4 ms·

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 calle

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.

chriswarbo 5y ago
I get the sentiment, but I think it's a fundamental error to equate "verbose" with "clear"/"simple"/"readable"/etc. and "compact" with "clever"/"fast"/"difficult"/etc. I see this so often that I wrote a blog post about it http://chriswarbo.net/blog/2020-02-08-clever_code.html http://chriswarbo.net/blog/2020-02-08-clever_code.html tl;dr trying to make things smaller isn't "clever", it's code golf; often, "clever" solutions just-so-happen to end up small. Likewise, spreading logic over many lines can lose abstraction; we can end up lost in a tangle of bools, ints, etc. without seeing the bigger picture.
- sumtechguy 5y ago
  Do not disagree at all. I almost always lean towards readability so I can make the next poor soul understand it (usually me 6 months from now). I once ended up with one of those 'clever' bits of code. It was the best solution because of the constraint we were in. But a co-worker (who helped create it) put it best 'no damn way are any of us going to be able to figure that out 6 months from now'. He was perfectly right, and it did take me 2 days to untangle it about a year later. That was comment time to for future me to put in what was this thing doing and why it worked the way it did (lesson learned). Getting that 'terse'/'readable' balance right can be tricky. Usually if some code is 'hard to read' it usually means it needs a bit of refactoring to shorten/length it up and make clear (with comments) what each bit is doing. You go drop something like duffs device into the middle of a parser you should put a comment on that. As not everyone has heard of it. If the code is going to be used a couple of times a year and if it takes an extra 15 seconds, so what. Comment it with 'hey this would be a good spot for duffs device?'. Most of the type of code I write these days runs so rarely and can take a bit of extra time. I am also working with jr devs who may or may not have read up on every cool trick. I am also playing with some code I got from the net. Some of these things have 5 page long functions, yep... totally lost in abstraction.

chriswarbo 5y ago

I get the sentiment, but I think it's a fundamental error to equate "verbose" with "clear"/"simple"/"readable"/etc. and "compact" with "clever"/"fast"/"difficult"/etc. I see this so often that I wrote a blog post about it http://chriswarbo.net/blog/2020-02-08-clever_code.html http://chriswarbo.net/blog/2020-02-08-clever_code.html tl;dr trying to make things smaller isn't "clever", it's code golf; often, "clever" solutions just-so-happen to end up small. Likewise, spreading logic over many lines can lose abstraction; we can end up lost in a tangle of bools, ints, etc. without seeing the bigger picture.

sumtechguy 5y ago
Do not disagree at all. I almost always lean towards readability so I can make the next poor soul understand it (usually me 6 months from now). I once ended up with one of those 'clever' bits of code. It was the best solution because of the constraint we were in. But a co-worker (who helped create it) put it best 'no damn way are any of us going to be able to figure that out 6 months from now'. He was perfectly right, and it did take me 2 days to untangle it about a year later. That was comment time to for future me to put in what was this thing doing and why it worked the way it did (lesson learned). Getting that 'terse'/'readable' balance right can be tricky. Usually if some code is 'hard to read' it usually means it needs a bit of refactoring to shorten/length it up and make clear (with comments) what each bit is doing. You go drop something like duffs device into the middle of a parser you should put a comment on that. As not everyone has heard of it. If the code is going to be used a couple of times a year and if it takes an extra 15 seconds, so what. Comment it with 'hey this would be a good spot for duffs device?'. Most of the type of code I write these days runs so rarely and can take a bit of extra time. I am also working with jr devs who may or may not have read up on every cool trick. I am also playing with some code I got from the net. Some of these things have 5 page long functions, yep... totally lost in abstraction.