Skip to main content
13 events
when toggle format what by license comment
Feb 23, 2018 at 12:35 comment added R. Schmitz @marcus Also, what happens if a test fails? Are you not going to debug it?
Feb 23, 2018 at 10:55 comment added Voo @JRE "they aren't allowed to produce garbage either. They have to deal with bad things gracefully and keep right on running." is a contradiction in itself. You can either keep on running in all situations (throw a big try catch block at the top level and install a few headers) or you can make sure to not cause inconsistencies. There are simply cases where you have to decide for one or the other.
Feb 23, 2018 at 6:48 comment added DonFusili @JRE I know these coding jobs exist and I do indeed count myself lucky mine isn't one of them. Mad respect to everyone that does thrive in your kind of environment. My comment was on this answer in this context,though. The question clearly indicates that crashing is allowed and as such I don't feel this answer does the situation justice.
Feb 22, 2018 at 22:55 comment added JRE @DonFusili: Count yourself lucky that you have the option to crash. My tasks aren't allowed to crash, and they aren't allowed to produce garbage either. They have to deal with bad things gracefully and keep right on running. They are allowed to complain in the logs so I can find out later what bad thing happened and how my code handled it.
Feb 22, 2018 at 20:57 comment added Rob K I have found that code that's easy to debug generally is code that doesn't need debugging.
Feb 22, 2018 at 18:07 comment added marcus I too was thinking this was going to be a nice answer but then it went the "just don't write bugs" route, which I can't upvote.
Feb 22, 2018 at 16:57 comment added DonFusili I would want to upvote you, except that I'm nitpicky about bs like "Code that doesn't crash is far easier to maintain". I prefer to maintain code that crashes with a clear cause to code that doesn't crash but just delivers a bad end result.
Feb 22, 2018 at 16:09 comment added Izkata Personally I prefer the more compact form, as long as there's styling around it like in my prior comment, because it guarantees less state to mentally keep track of - result_h1 cannot be reused if it doesn't exist, and the plumbing between the 4 variables is obvious.
Feb 22, 2018 at 16:08 comment added Izkata Question: Would you still say it's hard to read if F's arguments were split across lines? F(<newline>G1(H1(b1), H2(b2)),<newline>G2(c1)<newline>); (quick edit: CandiedOrange's answer is a more extreme version of this)
Feb 22, 2018 at 15:39 comment added leftaroundabout @MatthieuM. this can be an issue, though if the functions are well-known it is often obvious which takes how many arguments. Specifically, as I said, for infix functions it's immediately clear that they take two arguments. (Also, the parenthesized-tuples syntax most languages use exacerbates this problem; in a language that prefers Currying it's automatically clearer: F (G1 (H1 b1) (H2 b2)) (G2 c1).)
Feb 22, 2018 at 15:26 comment added Matthieu M. @leftaroundabout: To me, the difficulty is that it's not obvious whether G1 takes 3 parameters or only 2 and G2 is another parameter to F. I have to squint and count the parentheses.
Feb 22, 2018 at 14:43 comment added leftaroundabout While I agree that F(G1(H1(b1), H2(b2)), G2(c1)) is hard to read, this has nothing to do with being crammed too dense. (Not sure if you meant to say that, but it could be interpreted this way.) Nesting three or four functions in a single line can be perfectly readable, in particular if some of the functions are simple infix operators. It is the nondescriptive names that are the problem here, but that problem is even worse in the multi-line version, where yet more nondescriptive names are introduced. Adding only boilerplate almost never aids readability.
Feb 22, 2018 at 11:45 history answered David Arno CC BY-SA 3.0