4 ms·

In that example the constructor parameters were just moved, is there some cost in overloading the empty params? Original (labeled bad by the book): privat

In that example the constructor parameters were just moved, is there some cost in overloading the empty params? Original (labeled bad by the book): private void printGuessStatistics(char candidate, int count) { String number; String verb; String pluralModifier; Modified version: public class GuessStatisticsMessage { private String number; private String verb; private String pluralModifier; public String make(char candidate, int count) { createPluralDependentMessageParts(count); return String.format( "There %s %s %s%s", verb, number, candidate, pluralModifier ); } Once again, it was presented in the context of naming things....not object or data structures. Often one has to resort to spherical cows to explain things. (Edited to add the overloaded constructor params)

whstl 2y ago
> In that example the constructor parameters were just moved Not really. In the "Original" example there's no constructor in sight, as that's just a standalone procedural-style method, not a class. The second one turns the method into a class. > is there some cost As GP mentions, this incurs mental costs: "In more complex classes, it’s often hard to even identify that this has happened. Is this permanent object state, or just an internal temporary variable that made it easier to leap around methods?" In terms of performance, this depends on the language/runtime/type, but in general you'll get heap allocation instead of a stack, and it will use the GC. Also if the lifetime of the private fields is the same of GuessStatisticsMessage, so you'll waste memory if they're complex objects that don't need to live for as long as the class. Depends, YMMV. I once had a memory leak-ish issue due to that in a Ruby app. EDIT: > Once again, it was presented in the context of naming things....not object or data structures This is fine, but the example is not even good in terms of names. `make` is a terrible method name [1], and, turning local variables into long-lived object variables doesn't improve their names, it only muddies the waters like GP mentioned. [1] Classic parody/criticism of the style here: http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...
- nyrikki 2y ago
  It all doesn't matter, these are code fragments that are not in context of a full program. Lets look at the labels on these code blocks (in a chapter called "Chapter 2: Meaningful Names") > Listing 2-1 > Variables with unclear context. > Listing 2-2 > Variables have a context. What part of that would even suggest that they are indicating the most performant, idealized code? They are non-complete random code fragments meant to discuss one of the hardest problems in computer science...naming things. It is simply a poor example of "Variables have a context" being more readable than "Variables with unclear context", not a suggestion that the lifting principle is required. This is _simply_ an example that is similar to the extract and inversion method that all of us that get brought in to break up legacy monoliths have to do because often things are a big ball of much with vars that look more like it was written in the language Brainfuck or obfuscated Perl than anything reasonable. That is not anything that the Clean camp, or even Bob came up with...it is often the reality when trying to save systems from architectural erosion or.... But seriously if you consider 'clean code' as cargo culting design choices without though from any source, you are going to be screwed no matter what. The number of competing needs related to a dozen types of cohesion along with a dozen types of coupling will never reduce to a simple set of rules. Strings are interned either in the string pool, or even if you use New...which this code wasn't, anything newer than 8u20 will dedupe and duplicate strings will only have a single instance even if they aren't in the string pool. So long lived strings total space usage isn't really massive. If you choose to save the size of a pointer with what appears a short lived single computational class anyway, sacrificing readability and maintainability, you will have far greater problems than inefficient memory use.
  - whstl 2y ago
    > not a suggestion that the lifting principle is required. But there is such suggestion. In the quoted part of the book I sent above, Uncle Bob uses the words we need: https://news.ycombinator.com/item?id=42489167 https://news.ycombinator.com/item?id=42489167 - > This is _simply_ an example You asked where in the book the idea criticized by GP came from, and I only answered. I'm not trying to argue. - > What part of that would even suggest that they are indicating the most performant, idealized code? Nowhere. You're the one who asked for "the cost". I'm not in an argument, I'm only answering your questions.

whstl 2y ago

> In that example the constructor parameters were just moved Not really. In the "Original" example there's no constructor in sight, as that's just a standalone procedural-style method, not a class. The second one turns the method into a class. > is there some cost As GP mentions, this incurs mental costs: "In more complex classes, it’s often hard to even identify that this has happened. Is this permanent object state, or just an internal temporary variable that made it easier to leap around methods?" In terms of performance, this depends on the language/runtime/type, but in general you'll get heap allocation instead of a stack, and it will use the GC. Also if the lifetime of the private fields is the same of GuessStatisticsMessage, so you'll waste memory if they're complex objects that don't need to live for as long as the class. Depends, YMMV. I once had a memory leak-ish issue due to that in a Ruby app. EDIT: > Once again, it was presented in the context of naming things....not object or data structures This is fine, but the example is not even good in terms of names. `make` is a terrible method name [1], and, turning local variables into long-lived object variables doesn't improve their names, it only muddies the waters like GP mentioned. [1] Classic parody/criticism of the style here: http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...

nyrikki 2y ago
It all doesn't matter, these are code fragments that are not in context of a full program. Lets look at the labels on these code blocks (in a chapter called "Chapter 2: Meaningful Names") > Listing 2-1 > Variables with unclear context. > Listing 2-2 > Variables have a context. What part of that would even suggest that they are indicating the most performant, idealized code? They are non-complete random code fragments meant to discuss one of the hardest problems in computer science...naming things. It is simply a poor example of "Variables have a context" being more readable than "Variables with unclear context", not a suggestion that the lifting principle is required. This is _simply_ an example that is similar to the extract and inversion method that all of us that get brought in to break up legacy monoliths have to do because often things are a big ball of much with vars that look more like it was written in the language Brainfuck or obfuscated Perl than anything reasonable. That is not anything that the Clean camp, or even Bob came up with...it is often the reality when trying to save systems from architectural erosion or.... But seriously if you consider 'clean code' as cargo culting design choices without though from any source, you are going to be screwed no matter what. The number of competing needs related to a dozen types of cohesion along with a dozen types of coupling will never reduce to a simple set of rules. Strings are interned either in the string pool, or even if you use New...which this code wasn't, anything newer than 8u20 will dedupe and duplicate strings will only have a single instance even if they aren't in the string pool. So long lived strings total space usage isn't really massive. If you choose to save the size of a pointer with what appears a short lived single computational class anyway, sacrificing readability and maintainability, you will have far greater problems than inefficient memory use.
- whstl 2y ago
  > not a suggestion that the lifting principle is required. But there is such suggestion. In the quoted part of the book I sent above, Uncle Bob uses the words we need: https://news.ycombinator.com/item?id=42489167 https://news.ycombinator.com/item?id=42489167 - > This is _simply_ an example You asked where in the book the idea criticized by GP came from, and I only answered. I'm not trying to argue. - > What part of that would even suggest that they are indicating the most performant, idealized code? Nowhere. You're the one who asked for "the cost". I'm not in an argument, I'm only answering your questions.