521–530 of 552 posts
Earlier quoted context omitted.
Everything is made up. How do you organize people into being able to solve problems?
> How do you organize people into being able to solve problems? By not putting reductionist labels on them.
Earlier quoted context omitted.
True, but we shouldn't understate how beneficial elegant solutions can be in the appropriate setting. Sometimes you read code that gives you a new and memorable way to think about a certain kind of problem.
I agree we like it. I don't want to have to review it. I'd rather review code where the bugs stick out like blinking yellow lights, even if it runs 10% slower (or 1000% slower, if I'm only running it once.)
For example, suppose you have an application that connects to 17 queues and processes a different type of request from each. You could do this in lots of lines as follows:
var processors = new Processor[18];
processors[0] = client.CreateProcessor("FooQueue") { Handler = GetHandler("FooRequest") };
log.Write("Connected to Foo Queue");
...
processors[17] = client.CreateProcessor("BarQueue") { Handler = GetHandler("BarRequest") };
log.Write("Connected to Bar Queue");
var queues = new List { "Foo", ... , "Bar" };
var processors = queues.Select(q => client.CreateProcessor(q + "Queue") { Handler = GetHandler(q + "Request") };
Earlier quoted context omitted.
DRY isn't about not reimplementing things; it's about not literally copying and pasting code. Which I have seen all the time, and which some might find easier now but will definitely make the system harder to change (correctly) at some point later on.
But sometimes you should copy and paste code because those difference pieces of code can evolve independently. Knowing when to do this and when not to do this is what we do and no rule can blindly say one way or the other. Even the most obvious of functions like sin() and cos() may in some circumstances warrant a specialized implementation. Sure, for most stuff you should not have 10 copies of those all over the plac…
I think most programmers agree that simpler solutions (generally matching "lower cognitive load") are preferred, but the disagreements start about which ones are simpler: often a lower cognitive load comes with approaches one is more used to, or familiar with; when the mental models one has match those in the code. For instance, the article itself suggests to use early/premature returns, while they are sometimes comp…
A lack of nuance about this kind of thing is part of what enrages me when ChatGPT tries to tell be a planned change or design is going to be “elegant” or “simple”. It’s like… maybe yes, maybe no, but those are not binary terms and throwing them around like that makes it sound like an enthusiastic intern sucking up to his sensei rather than a digital brain whose thoughts are formed by having ingested billions of lines…
Earlier quoted context omitted.
I found this type of approach (where you try to meet subjective readability goals with objective/statistical metrics) to not produce clear code in practice. Instead, I suggest this one weird trick: if your colleagues are confused in code review, then rewrite and comment the code until they aren't confused anymore. Don't just explain it to them ad-hoc, make the code+comments become the explanation. There is no better…
It's one message I struggle to convey to people I do code reviews for: don't make me understand it, make it more self explanatory so every reader does. (And, yes, I ask for it explicitly too) (I sometimes "ask" questions for something it took me a few back and forths through code to get so they'd think about how it could be made clearer) Unfortunately, most people focus on explaining their frame of mind (insecurity?)…
Earlier quoted context omitted.
A lack of nuance about this kind of thing is part of what enrages me when ChatGPT tries to tell be a planned change or design is going to be “elegant” or “simple”. It’s like… maybe yes, maybe no, but those are not binary terms and throwing them around like that makes it sound like an enthusiastic intern sucking up to his sensei rather than a digital brain whose thoughts are formed by having ingested billions of lines…
your rage suggests that you think ChatGPT is making value judgements about elegance or simplicity. You surely know where it picked up those concepts don't you?
Earlier quoted context omitted.
> You would feel the need to look up a variable called isSecure, but would not need to look up condition4 or condition5? I assume that those "conditions" are placeholders, not to be read literally in the example (since the example is not about poorly named variables, but about complex conditions), so I did not mean them literally, either. Supposedly those would be more informative names, such as "channel_encrypted",…
Well, from my experience, as well as from tools figuring out complexity of functions (so, seems to be accepted and not my personal preference), nested ifs add to cognitive load. So, we know that early returns are easier to understand. In a lot of code reviews, I am in debates how to name things. I know the juniors are cross with me, as if it's bike shedding, but it's important for clarity when reading/debugging. ---…
I think most programmers agree that simpler solutions (generally matching "lower cognitive load") are preferred, but the disagreements start about which ones are simpler: often a lower cognitive load comes with approaches one is more used to, or familiar with; when the mental models one has match those in the code. For instance, the article itself suggests to use early/premature returns, while they are sometimes comp…
> one would have to look up what "isSecure" means, while "(condition4 && !condition5)" would have shown it at once You would feel the need to look up a variable called isSecure , but would not need to look up condition4 or condition5 ? I think the point TFA was making is that one could read isSecure and assume what kind of implementation to expect, whereas with condition4 I wouldn't even know what to look for, or I'd…