4 ms·

This isn't a good idea. And his functions, well... they're gross. You're going to replace orderCost = orderCost - shipping; with ApplyFreeShipping(); No

by smabie 6y ago

This isn't a good idea. And his functions, well... they're gross. You're going to replace orderCost = orderCost - shipping; with ApplyFreeShipping(); Now you've violated referential transparency, introduced some unnecessary global and mutable state, and not really made anything clearer. Let's take his other example: var outstanding = GetOutstandingOrders(); Into var allOutstandingOrders = GetOutstandingOrders(); Please for the love of god, no. Variable names should be short, and in my controversial opinion, as short as possible. Long variable names actually make code more difficult to understand, not easier. Rob Pike talks about it in the Practice of Programming, and it's a common tenant among APL/J/K programmers as well. Here's how I wish programs were structured: 1) Make your code as terse and dense as possible so you can see as much of it at one time as possible (see code written by Arthur Whitney). 2) Make your variable names abbrevations or acronyms, like instead of 'convertInt', call it 'ci'. 3) Comment every function and keep each function to only a couple lines. 4) Because your functions are so small and dense, you'll never need to modify them, only throw them away. 5) Bam, your comments and never out of date because the functions you're writing never need to be modified, only deleted. Unfortunately, most programming languages don't give you sufficient power to do anything in a couple lines. Which brings up the question, why don't we switch to those that do? Honestly, J or K would be totally usable for the vast majority of programming problems.

davethedevguy 6y ago
I agree that the examples aren't great. I struggled to come up with terse examples to illustrate the point, but I stand by the general premise of the post. I'm afraid I can't agree with making variable names as short as possible as a general rule, though. I think that the length of the variable name should be linked to a) how long it lives for and b) the distance between the declaration and the usage. For example, I'm personally OK with using 'i' for the index in a 'for' loop, but stand by longer names such as 'allOutstandingOrders' for variables that are used throughout a function, where the declaration isn't within a few lines of the usage.
chimprich 6y ago
I agree that variables names should be short, but not "as short as possible". They should be as short as possible while remaining unambiguous and avoiding loading short-term memory. "allOutstandingOrders" does not look to me like a long variable name. > Make your code as terse and dense as possible I really hope I never get to work with any code you've written. > Make your variable names abbrevations or acronyms, like instead of 'convertInt', call it 'ci' I'm starting to think this comment is satire now. If I have to read the comments on a function or variable to figure out what it does then my productivity is going to be absolutely kneecapped if I'm a newcomer to your project.
schlupa 6y ago
Length (as proxy of expressiveness) of variable name should be a function of the scope of the variable. It there are only a few lines between declaration and last use of a variable a single letter name is often suffcient (i,j,k for loop vars, p, q, r for pointers, l for length, n,m for upper bounds, a,b,c,t, etc. for temporaries. If the scope is over a longer section, without to much repetition it is appropriate to have a longer name. If it is a global variable with external linkage, it is very good to have a descriptive name so that it is also clear what it is when looking from outside.
kelnos 6y ago
Heartily disagree. If I see a method/variable named something like "ci", I will reject it in code review. Descriptive variable and function names make code easier to understand, not harder.
rootlocus 6y ago
> 1) Make your code as terse and dense as possible so you can see as much of it at one time as possible (see code written by Arthur Whitney). Why? I don't want to see as much code as possible. I want to see the code I'm interested in. If I can read 4 lines of code and understand what it does, I spend less time and energy than reading 20 lines of code and trying to reverse engineer it. > 2) Make your variable names abbrevations or acronyms, like instead of 'convertInt', call it 'ci'. That makes no sense, it's gross and has only drawbacks. > 3) Comment every function and keep each function to only a couple lines. So you need one or more comments for two lines of code? > 4) Because your functions are so small and dense, you'll never need to modify them, only throw them away. If you're only writing them to throw them away, why not optimize and never write them in the first place? > 5) Bam, your comments and never out of date because the functions you're writing never need to be modified, only deleted. This is sarcasm, right? I feel like I've been trolled.
sradman 6y ago
Perhaps we need smart refactoring for our identifier names that remove redundant words (eg “all”) and replace long words with shorter synonyms (eg pending vs outstanding). var pendingOrders = getPendingOrders()
IggleSniggle 6y ago
I appreciate the idea of density allowing you to "see" the bigger picture better. It's something I value too. But ideally you can find a balance between the best of both worlds. Why in the world would you comment every function if you could just embed the comment into the code? x@>#:'x sort order alphabetically in place does not to me seem substantially different from order = alphaSort(order) When the comment is embedded into the function, the same effect you described (~"because your functions are small, you can throw your comments away with the function "). These variable and function names need not stick around any more than K comments. Ideally, the name only exists for as long as it has utility, and if it has no utility, it is an anonymous function / never stored in a variable. If there is marginal utility in the name, then sure, use a single character placeholder `o=>sort(compareFn)`. As soon as you need to hold onto an idea of a noun (as in a larger mutating reference frame) or a verb (as in any function you want to both compose and reuse), then names become helpful handles for reasoning about the code over time and opportunities for reuse, `alphaSort=sort(alphaCompareFn); sortedOrders=alphaSort(rawOrders)`. If there's no opportunity for reuse or if the function is trivial, THEN eliminate the longer names. The harder part here is the middle area. With very concise code, you can see the whole thing, but with sufficient complexity, you may not be able to hold what "o" is at any given time in your head. With verbose code, the code will read like highly precise English and you are unlikely to be confused about what "alphaSortedOrders" means, but you might lose track of what the larger program is doing. The real problems arise in the middle: is "orders" my sorted or unsorted orders? If it's not concise enough, you can't immediately see it, and if it's not verbose enough, you don't have a handle on what it is you are operating on. --- Verbose code helps for transferomg "comments" across code boundaries, as when looking at the function signature when calling a function. I don't see how this is substantively longer than doing the same thing with a comment, and it provides additional utility for contextualizing chunks of code. When you change the "job" of the code, you change the variable name at the same time. So while within some complex and mutating function you might want "rawSortedOrders", in some other context where you already know what you have, you strive for density. finalizedOrders = rawSortedOrders.map( o=>o.id=guid() ) or finalizedOrders = rawOrders.pipe( sort(localeCompare), map(o=>o.id=guid()) )
nailer 6y ago
> Variable names should be short, and in my controversial opinion, as short as possible. Long variable names actually make code more difficult to understand, not easier. Rob Pike talks about it in the Practice of Programming, and it's a common tenant among APL/J/K programmers as well. https://en.wikipedia.org/wiki/Argument_from_authority https://en.wikipedia.org/wiki/Argument_from_authority But as short as possible doesn't mean: > Make your variable names abbrevations or acronyms, like instead of 'convertInt', call it 'ci'. 'ci' has no meaning. It is not a possible name for 'convertInt' because 'ci' is not a name. I have to visit the function to determine what 'ci'-ing something does. In 'ci', in turn, I'll have to deal with more minified code.
happytoexplain 6y ago
I couldn't disagree more about variable name length, unless you're writing complex math where a variable is referenced a dozen times in one function.
karmakaze 6y ago
Specifically in this case it was: if (customersFirstOrder) { ApplyFreeShipping(); } when really the `if` should be inside ApplyFreeShipping as it is part of its rules: when and how. We just 'enable' free shipping as it applies.
karmakaze 6y ago
Variable naming is secondary here. Why isn't this the body of a `ProcessOutstandingOrders` method? var outstanding = GetOutstandingOrders(); ... Process(outstanding);

by smabie 6y ago

davethedevguy 6y ago

I agree that the examples aren't great. I struggled to come up with terse examples to illustrate the point, but I stand by the general premise of the post. I'm afraid I can't agree with making variable names as short as possible as a general rule, though. I think that the length of the variable name should be linked to a) how long it lives for and b) the distance between the declaration and the usage. For example, I'm personally OK with using 'i' for the index in a 'for' loop, but stand by longer names such as 'allOutstandingOrders' for variables that are used throughout a function, where the declaration isn't within a few lines of the usage.

chimprich 6y ago

I agree that variables names should be short, but not "as short as possible". They should be as short as possible while remaining unambiguous and avoiding loading short-term memory. "allOutstandingOrders" does not look to me like a long variable name. > Make your code as terse and dense as possible I really hope I never get to work with any code you've written. > Make your variable names abbrevations or acronyms, like instead of 'convertInt', call it 'ci' I'm starting to think this comment is satire now. If I have to read the comments on a function or variable to figure out what it does then my productivity is going to be absolutely kneecapped if I'm a newcomer to your project.

schlupa 6y ago

Length (as proxy of expressiveness) of variable name should be a function of the scope of the variable. It there are only a few lines between declaration and last use of a variable a single letter name is often suffcient (i,j,k for loop vars, p, q, r for pointers, l for length, n,m for upper bounds, a,b,c,t, etc. for temporaries. If the scope is over a longer section, without to much repetition it is appropriate to have a longer name. If it is a global variable with external linkage, it is very good to have a descriptive name so that it is also clear what it is when looking from outside.

kelnos 6y ago

Heartily disagree. If I see a method/variable named something like "ci", I will reject it in code review. Descriptive variable and function names make code easier to understand, not harder.

rootlocus 6y ago

> 1) Make your code as terse and dense as possible so you can see as much of it at one time as possible (see code written by Arthur Whitney). Why? I don't want to see as much code as possible. I want to see the code I'm interested in. If I can read 4 lines of code and understand what it does, I spend less time and energy than reading 20 lines of code and trying to reverse engineer it. > 2) Make your variable names abbrevations or acronyms, like instead of 'convertInt', call it 'ci'. That makes no sense, it's gross and has only drawbacks. > 3) Comment every function and keep each function to only a couple lines. So you need one or more comments for two lines of code? > 4) Because your functions are so small and dense, you'll never need to modify them, only throw them away. If you're only writing them to throw them away, why not optimize and never write them in the first place? > 5) Bam, your comments and never out of date because the functions you're writing never need to be modified, only deleted. This is sarcasm, right? I feel like I've been trolled.

sradman 6y ago

Perhaps we need smart refactoring for our identifier names that remove redundant words (eg “all”) and replace long words with shorter synonyms (eg pending vs outstanding). var pendingOrders = getPendingOrders()

IggleSniggle 6y ago

I appreciate the idea of density allowing you to "see" the bigger picture better. It's something I value too. But ideally you can find a balance between the best of both worlds. Why in the world would you comment every function if you could just embed the comment into the code? x@>#:'x sort order alphabetically in place does not to me seem substantially different from order = alphaSort(order) When the comment is embedded into the function, the same effect you described (~"because your functions are small, you can throw your comments away with the function "). These variable and function names need not stick around any more than K comments. Ideally, the name only exists for as long as it has utility, and if it has no utility, it is an anonymous function / never stored in a variable. If there is marginal utility in the name, then sure, use a single character placeholder `o=>sort(compareFn)`. As soon as you need to hold onto an idea of a noun (as in a larger mutating reference frame) or a verb (as in any function you want to both compose and reuse), then names become helpful handles for reasoning about the code over time and opportunities for reuse, `alphaSort=sort(alphaCompareFn); sortedOrders=alphaSort(rawOrders)`. If there's no opportunity for reuse or if the function is trivial, THEN eliminate the longer names. The harder part here is the middle area. With very concise code, you can see the whole thing, but with sufficient complexity, you may not be able to hold what "o" is at any given time in your head. With verbose code, the code will read like highly precise English and you are unlikely to be confused about what "alphaSortedOrders" means, but you might lose track of what the larger program is doing. The real problems arise in the middle: is "orders" my sorted or unsorted orders? If it's not concise enough, you can't immediately see it, and if it's not verbose enough, you don't have a handle on what it is you are operating on. --- Verbose code helps for transferomg "comments" across code boundaries, as when looking at the function signature when calling a function. I don't see how this is substantively longer than doing the same thing with a comment, and it provides additional utility for contextualizing chunks of code. When you change the "job" of the code, you change the variable name at the same time. So while within some complex and mutating function you might want "rawSortedOrders", in some other context where you already know what you have, you strive for density. finalizedOrders = rawSortedOrders.map( o=>o.id=guid() ) or finalizedOrders = rawOrders.pipe( sort(localeCompare), map(o=>o.id=guid()) )

nailer 6y ago

> Variable names should be short, and in my controversial opinion, as short as possible. Long variable names actually make code more difficult to understand, not easier. Rob Pike talks about it in the Practice of Programming, and it's a common tenant among APL/J/K programmers as well. https://en.wikipedia.org/wiki/Argument_from_authority https://en.wikipedia.org/wiki/Argument_from_authority But as short as possible doesn't mean: > Make your variable names abbrevations or acronyms, like instead of 'convertInt', call it 'ci'. 'ci' has no meaning. It is not a possible name for 'convertInt' because 'ci' is not a name. I have to visit the function to determine what 'ci'-ing something does. In 'ci', in turn, I'll have to deal with more minified code.

happytoexplain 6y ago

I couldn't disagree more about variable name length, unless you're writing complex math where a variable is referenced a dozen times in one function.

karmakaze 6y ago

Specifically in this case it was: if (customersFirstOrder) { ApplyFreeShipping(); } when really the `if` should be inside ApplyFreeShipping as it is part of its rules: when and how. We just 'enable' free shipping as it applies.

karmakaze 6y ago

Variable naming is secondary here. Why isn't this the body of a `ProcessOutstandingOrders` method? var outstanding = GetOutstandingOrders(); ... Process(outstanding);