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

Why most “clever” code ain’t so clever after all

drive.google.com

Post reply on HN
Print view View original

31–40 of 104 posts

Re: Why most “clever” code ain’t so clever after all

#31

Post by segmondy »

iagorodriguez wrote: post #7

I run a small dev company. This is the first lessons we teach our programmers. If your code cant be understood by someone else with minimal efforts it is not good enough.

This is a very delicate subject. If the program is using language constructs and can't be understood because the reading programmer doesn't know it, then who's fault is it?

why have multiline if/else when a tenary operator can do?

I rather read a = b ? c : d; than possibly 4 lines of code, p/s ignore the names of the variable.

There are plenty of code out there that are so easy to understand if you read them one line at a time, but very difficult to see the big picture, say there is a method being called as follows foo->dostuff(bar).

The issue is there is so many layers between calling dostuff() and something interesting happening. because dostuff calls nextstuff() and nextstuff() calls stuffafternextstuff(). The code is easy to read but terrible and tough to unravel.

There is only so much anyone can hold in their head at once, a bit complex but 2 layers deep is better than so simple to understand one line at a time but 10 layers deep.

Re: Why most “clever” code ain’t so clever after all

#32

Post by emblem21 »

atoko wrote: post #28
emblem21 wrote: post #23

for(var i in list) { (function(element) { someAsyncCallThatNeedsTheRightIndexedElement(element); })(list[i]); } I've seen people grumble that this is " too clever " I've been known to snap back " Bootcamps don't have a monopoly on what technical solutions are valid " Pointers are probably too clever for most people. Admittedly, goto is too clever for me. :(

Try using .call

The binding of the element to the lexical scope is done for later executions. .call is immediate.

Re: Why most “clever” code ain’t so clever after all

#33

Post by junto »

As a company we use C# and Visual Studio as an IDE.

Everyone has Resharper, which is undoubtedly an invaluable tool. However, Resharper had a feature that will convert for/for each loops with conditional logic into LINQ lambdas.

For simple cases I find it's conversion useful and readable, but for more complex cases it becomes an unreadable nightmare for anyone bug fixing later on. I find that to be the case even when I personally wrote the original code, so I avoid these conversions whenever they become overly complicated.

Re: Why most “clever” code ain’t so clever after all

#34

Post by squeaky-clean »

I understand what they're getting at, but I think the final listing is even more "clever" than the first. The first one I could read and understand pretty easily, and I've never written Haskell. The few things it does, and how, are easy to spot. The final one is harder to understand at a glance, even though it's more generalized. Some people take it even further than that, to where the implementation is totally abstracted from it's only uses.

If you removed the "fizzbuzz" related names from the code, could you tell that listing 4 is being used for a FizzBuzz? Sometimes a 3&5 FizzBuzz is just a 3&5 FizzBuzz and nothing more, and doing anything further is akin to premature optimization. Planning is hard, haha.

I realize FizzBuzz is a toy solution for the sake of example, and the solution with fewer assumptions is more often the better choice when dealing with larger problems, overall this was a very good article. But we also need more programmers to understand that if you're writing an internal backend function which is passed a date-as-integer, you probably don't need to double check that it's actually string representation of the integer, or an ISO formatted date, or YYYY-MM-DD formatted string, or YY-MM-DD formatted string, or....

Re: Why most “clever” code ain’t so clever after all

#35

Post by kylemuir »

junto wrote: post #33

As a company we use C# and Visual Studio as an IDE. Everyone has Resharper, which is undoubtedly an invaluable tool. However, Resharper had a feature that will convert for/for each loops with conditional logic into LINQ lambdas. For simple cases I find it's conversion useful and readable, but for more complex cases it becomes an unreadable nightmare for anyone bug fixing later on. I find that to be the case even when…

Thankfully, it also has the same "Alt-Enter" to revert said LINQ query :)

Re: Why most “clever” code ain’t so clever after all

#36

Post by mpweiher »

Code can be clever to allow (significantly more) other code to be simple.

For example, we are using Higher Order Messaging[1] to turn this:

   if ( [delegate respondsToSelector:@selector(doSomethingElse:)]) {
      [delegate doSomething:self];
   }
into this:

   [[delegate ifResponds] doSomething:self];
Yes, the implementation of -ifResponds is slightly clever, though I've gotten it simpler over time, but it certainly is worth it in the simplification of client code.

Engineers manage tradeoffs. That's what makes them engineers.

[1] https://en.wikipedia.org/wiki/Higher_order_message

Re: Why most “clever” code ain’t so clever after all

#37

Post by sixbrx »

emn13 wrote: post #18
johnfn wrote: post #10

Cycled lists and the modulo operator are two different abstractions for thinking about the same problem, in the same vein of "blind men grasping at elephant." They are different perspectives on the similar problem. The reason we think that cycling a list is "clever" but using modulo is "boring" is because most of us use modulo often, and cycling rarely. There is nothing inherently "clever" about either of the two app…

The issue with the first fizzbuzz isn't just cylcling lists, it's also the use of zipWith. At least, that's what causes some of the brittleness in his examples. --- Also, I think you're slightly wrong in that cycled lists and modulo are "just different abstractions" - they may be to a machine, but they are not to people. And in this case, critically, the original problem's phrasing is much closer to the modulo implem…

> problem's phrasing is much closer to the modulo implementation

But I take the problem description as only describing a specification of what output is wanted, I don't think it's intended as a guidelines of how it should be implemented internally. If teams I've been on ever implemented things as some of our clients imagined they would work (which we had to sit through while trying to coerce some coherent requirements from them) we'd have been in a world of hurt :)

Re: Why most “clever” code ain’t so clever after all

#38

Post by Jach »

emblem21 wrote: post #32
atoko wrote: post #28

Earlier quoted context omitted.

Try using .call

The binding of the element to the lexical scope is done for later executions. .call is immediate.

I think they meant try using .call and see the 'too clever' remarks come in. I'll delete this if they clarify...

Re: Why most “clever” code ain’t so clever after all

#39

Post by squeaky-clean »

ezyang wrote: post #24

I didn't make it past the fizzbuzz example. But I wouldn't call the solution with cycle all that clever. Here's a better one: https://themonadreader.files.wordpress.com/2014/04/fizzbuzz.... the punchline reproduced below: fizzbuzz' :: Int -> String fizzbuzz' n = (test 3 "fizz" . test 5 "buzz") id (show n) where test d s x | n `mod` d == 0 = const (s ++ x "") | otherwise = x fizzbuzz :: [String] fizzbuzz = map fizzbuz…

Feature request: Client should be able to specify either 3, or 1023 for the number needed to print "fizz."

Feature request: Client should be able to optionally request "Lizard" as another string whenever the number is a multiple of 13.

That's what the article is referring to. Your function may be more clever, but it's more specific, works in only exactly the requested cases and is harder to change.

Re: Why most “clever” code ain’t so clever after all

#40

Post by yoklov »

wangchow wrote: post #27

So long as the "cleverness" is well-documented it's not a problem. Authors should explain why it is written the way it is. Problem solved. I've seen some weird-ass calculations in code with no comments. If the author has gone through so much effort to come up with the clever solution why not add some commentary so the next guy can read it quickly. That's why every language has support for comments..

OTOH comments easily become outdated, and it's painfully easy to make a change that subtly invalidates a comment in another file. They're like lines of code that is never tested or run.

For calculations, I'm not really sure I agree either. I used to work in games, specifically on physics and collision, and there's a point at which you have to assume that the person maintaining it has a reasonable level of familiarity with the subject matter, or else you'd need to write a comment that contains all of a linear algebra course.

Post reply on HN