On Thu, 08 Nov 2018 18:13:55 +0100, Jacob Carlborg wrote:
> I guess we have very different ideas on what "small scope" is. For me it means around 10 lines. Here's an example in the DMD code base, the method for doing the semantic analyze on a call expression [1]. It's 902 lines long and has a parameter called "exp". Another example, the semantic analyze for an is expression [2], 310 lines long. It has a parameter called "e".

I recall opening up the source code some years ago, encountering a long function, and seeing variables `e` and `e2` that were reused for *probably* different purposes but I honestly couldn't tell.

Having them named `expression` and `expression2` would have saved me about five seconds total, which wouldn't have been particularly worthwhile. Giving them names that reflected how they were being used would have been quite helpful -- at the very least, it would have given a weak indication that they were not being reused for different purposes.

On Thu, Nov 08, 2018 at 06:13:55PM +0100, Jacob Carlborg via Digitalmars-d-announce wrote: [...]
> I guess we have very different ideas on what "small scope" is. For me it means around 10 lines. Here's an example in the DMD code base, the method for doing the semantic analyze on a call expression [1]. It's 902 lines long and has a parameter called "exp". Another example, the semantic analyze for an is expression [2], 310 lines long. It has a parameter called "e".
> 
> Someone familiar with the code base might know that the convention is that a variable of a type inheriting from the Expression class is usually called "e". Someone new to the code base will most likely not. I cannot see how starting to call the variable "expression" or "callExpression" would be disrupt. Currently when someone familiar with the code base reads the code and sees a variable named "e" the developer will think "hey, I know by convention that is usual an expression". If the variable was renamed to "expression" then both the one familiar and unfamiliar with the code base can immediately read that this variable holds an expression.
[...]

A function parameter named 'expression' is far too long. I wouldn't go as far as calling it 'e', but maybe 'expr' is about as long as I would go.  You're dealing with the code of a compiler, 'expr' should be blatantly obvious already that it means "expression".  Spelling it out completely just clutters the code and makes it harder to read.


T

-- 
Three out of two people have difficulties with fractions. -- Dirk Eddelbuettel

On Thursday, 8 November 2018 at 18:15:55 UTC, Stanislav Blinov wrote:
>
> One keystroke (well ok, two keys because it's *) ;)
> https://dl.dropbox.com/s/mifou0ervwspx5i/vimhl.png
>

What sorcery is this? I need to know. I guess its vim but how does it highlight symbols?

On Thu, 08 Nov 2018 18:38:55 +0000, welkam wrote:
> On Thursday, 8 November 2018 at 18:15:55 UTC, Stanislav Blinov wrote:
>>
>> One keystroke (well ok, two keys because it's *) ;)
>> https://dl.dropbox.com/s/mifou0ervwspx5i/vimhl.png
>>
>>
> What sorcery is this? I need to know. I guess its vim but how does it highlight symbols?

By default, when you search for something in vim, it highlights all matches (as well as moving the cursor to the next match). The '*' command is 'search for the word under the cursor'.

The rest is just basic syntax highlighting.

On Thu, Nov 08, 2018 at 05:50:20PM +0000, welkam via Digitalmars-d-announce wrote:
> On Wednesday, 7 November 2018 at 22:08:36 UTC, H. S. Teoh wrote:
> > I don't speak for the compiler devs, but IMO, one-letter variables are OK if they are local, and cover a relatively small scope.
> 
> By saying more descriptive I should have clarified that I meant to change them to 3-7 letter names. Small variable names are ok for small functions like the one in attrib.d called void importAll(Scope* sc). It has variable named sc and its clear where it is used.
> 
> Now for all of you who think that one letter variables are ok here is exercise. Go and open src/dmd/func.d with your favorite code editor. Find function FuncDeclaration resolveFuncCall(). Its around 170 LOC long. Now find all uses of variable Dsymbol s. Did you found them all? Are you sure?

Yes. My editor knows to search for 's' delimited by word boundaries, so it would not match 's' in the middle of the word, but only 's' surrounded by non-alphabetic characters.


> Ok now do the same for variable loc. See the difference?

I see no difference.

Moral: use a better editor. :-P


> > Java-style verbosity IMO makes code *harder* to read because the verbosity gets > in your face, crowding out the more interesting (and important) larger picture of code structure.
> 
> What editor do you use?

Vim.

And I don't even use syntax highlighting (because I find it visually
distracting).


> Here is the worst example to prove my point but its still sufficient. All
> editors worth your time highlights the same text when selected and here is
> example of one letter variable.
> https://imgur.com/a/jjxCdmh
> and tree letter variable
> https://imgur.com/a/xOqbkmn

Your syntax highlighter is broken.  It should not match substrings, but only the entire word.  Vim's search function does this (including the highlights, if I turned it on, but by default I leave it off).


> where is all that crowding and loss of large picture you speak of? Its the opposite. Code structure is more clear with longer variable names than one letter.

Your opinion is biased by using a flawed syntax highlighter / symbol search function.


> > As Walter said in his recent talk, the length of variable names (or identifiers in general, really) should roughly correspond to their scope
> 
> At best this is argument form authority. You said how thing should be not why. For argument sake imagine situation where you need to expand function.  By your proposed rules you should rename local variables to longer names.  Thats ridiculous. Yes I watched that presentation and fully disagree with Walter and know for sure he doesnt have sound argument to support his position.
[...]

It's very simple.  The human brain is very good at context-sensitive pattern matching, something which computers are rather poor at (well, at least, traditional algorithms that aren't neural-network based). Natural language, for example, is full of ambiguities, but in everyday speech we have no problems figuring out what is meant, because the context supplies the necessary information to disambiguate.  Therefore, frequently-used words tend to be short (and tend to shorten over time), because it's not necessary to enunciate the full word or phrase to convey the meaning.  Rarely-used words tend to be longer (and resist simplification over time) because context provides less information, and so the full word becomes necessary in order to minimize information loss.

Function parameters and local variables are, by definition, restricted in scope, and therefore the context of the function provides enough information to disambiguate short names.  And since local variables and parameters would tend to be used frequently, the brain prefers to simplify and shorten their identifiers.  As a result, after acclimatizing, one begins to expect that short names correspond with local variables, and long names correspond with non-local variables. Going against this natural expectation (e.g., long names for locals, short names for globals) causes extra mental load to resolve the referents.

Your counterargument of expanding a function and needing to rename local variables is a strawman.  A function is a function, and local variables don't need to be renamed just because you added more code into it.

(However, there *is* a point that when the function starts getting too long, it ought to be split into separate functions, otherwise it becomes harder to understand. On that point, I do agree with you that dmd's code could stand improvement, since 900-line functions are definitely far too long to keep the entire context in short-term memory, and so using short local identifiers begins to lose its benefits and increase its disadvantages.)


T

-- 
Many open minds should be closed for repairs. -- K5 user

On Thu, Nov 08, 2018 at 06:38:55PM +0000, welkam via Digitalmars-d-announce wrote:
> On Thursday, 8 November 2018 at 18:15:55 UTC, Stanislav Blinov wrote:
> > 
> > One keystroke (well ok, two keys because it's *) ;)
> > https://dl.dropbox.com/s/mifou0ervwspx5i/vimhl.png
> > 
> 
> What sorcery is this? I need to know. I guess its vim but how does it highlight symbols?

As I've said, it highlights symbols based on *word* match, not substring match, which apparently your editor does.  The latter is flawed, and probably is what led you to your conclusions.  I suggest looking for an editor with a better syntax highlighter / search function.


T

-- 
The peace of mind---from knowing that viruses which exploit Microsoft system vulnerabilities cannot touch Linux---is priceless. -- Frustrated system administrator.

On Thursday, 8 November 2018 at 18:48:05 UTC, Neia Neutuladh wrote:
> On Thu, 08 Nov 2018 18:38:55 +0000, welkam wrote:
>> On Thursday, 8 November 2018 at 18:15:55 UTC, Stanislav Blinov wrote:
>>>
>>> One keystroke (well ok, two keys because it's *) ;)
>>> https://dl.dropbox.com/s/mifou0ervwspx5i/vimhl.png
>>>
>>>
>> What sorcery is this? I need to know. I guess its vim but how does it highlight symbols?
>
> By default, when you search for something in vim, it highlights all matches (as well as moving the cursor to the next match). The '*' command is 'search for the word under the cursor'.

"Near", not "under". But yup, key is "word", i.e. with a very concise keystroke you get a highlighted search for a (in that case) "\<m\>". If I were to search for just "m", I'd get the same soup as in welkam's first screenshot.

On Thursday, 8 November 2018 at 18:52:02 UTC, H. S. Teoh wrote:
> length is getting ridiculous

Having better editor support is nice but by "use better editor" you meant use vim dont you? And even if I switch to vim it wont solve my initial objection to one letter variable names. Its needless hurdles. Not to mention the next person new to this will likely have same problems like me. And the person after that etc. Which comes to my recurring thought when dealing with dmd. How the f@#k should I knew that? Documentation and instructions around D project is almost non existant. Does idea pit of success not apply to compiler?


Human brain is good at finding patterns. Its also good at finding patters it wants to find where they dont exist. Your statement that humans have no problems in disambiguating language is completely false. Most people just ignore logical conflicts or lack of information needed to correctly understand what is being said. Most people dont put lots of effort in understanding what exactly is being said and humans are bad at conveying their thoughts trough words to begin with. Extreme case of this is all forms of religious believes. Here is a clip where people give definitions of God and none of them are the same
https://youtu.be/HhRo9ABvef4
and here is one where J.P. at least tries to disambiguate words.
https://youtu.be/q0O8Jw6grro

When people talk about God first they cant tell precisely what they believe. Second they dont know precisely what others believe. And third it doesnt even matter as long as you make vaguely sounding sentences. Same extends to the rest of human interactions and humans would happily go without noticing that until they have to interact with computers where you have to define everything precisely.

Your second idea that shorter words have less information is... just... What? English is not floating point where length dictates precision. In German maybe with one word created from combining multiple but not in English.

Then you combined your both flawed ideas to produce paragraph where good and bad ideas are mixed together.

No I did not strawman. I took Walters advice from NWCPP talk precisely to show a flow in it. If variable name lenght should be related to scope then changing scope should change variable name lenght. You on the other hand changed advice to binary advice. Either local and short or global and verbose
NWCPP talk
https://youtu.be/lbp6vwdnE0k?t=444

Code is read more often than written and should be optimized for that. One letter variable names are not descriptive enough. In short functions you can get away from paying mental price but in long ones you do not.

On 11/8/2018 9:23 AM, welkam wrote:
> And where can i read about naming convention? My guess its not documented anywhere and would not be in foreseeable future or ever. Also are you sure you are not talking about two letter variables like
> sc for scope
> fd for function declaration
> td for template declaration

That is a naming convention. No, it's not documented. There's also `e` for Expression. `i` for loop index. Etc.


> What I want to do is change variables like m. Try guessing what it is used for.

I don't need to guess. I look at its declaration a few lines up.


> What I dont understand is that you are against changing variable names that would improve code understandability

This is where we diverge:

    Expression expression = new IntegerExp(loc, 1);
    expression = expression.expressionSemantic(sc);
    expression = resolveProperties(sc, expression);

is just exhausting compared with:

    Expression e = new IntegerExp(loc, 1);
    e = e.expressionSemantic(sc);
    e = resolveProperties(sc, e);


> but you are not against changing for loops to foreach that add almost nothing to code readability and only look better.

Looking better is improving readability.

    foreach (m; modules)
    {
         ...
    }

is much more readable than:

    for (size_t i = 0; i < modules.dim; ++i)
    {
         Module m = modules[i];
         ...
    }

and much less prone to typo bugs. The for loop also is dependent on abstraction leak of modules[] being an array, whereas foreach only requires that the abstraction be traverse-able.


> What you dont know about me is that I worked as code reviewer/tester/merger at PHP shop and know full well why you want pull requests the way you want. I also know how much less easier it is to review simple changes like foreach loop changes and simple variable renaming

It's great that you have valuable experience with this. Renaming variables, however, is not what I'm looking for. What I am looking for is using D to fix leaky abstractions, using const and pure, minimizing use of global mutable state, reducing the amount of code one must learn to make useful changes, reducing code duplication, minimizing the lifetime of variables, improving performance, etc.

For some more thoughts on this, check out my recent presentation on it:

http://nwcpp.org/october-2018.html

On Thursday, 8 November 2018 at 08:40:37 UTC, Joakim wrote:
[...]
>
> 2.080.1 - 1D  8.0s
> 2.081.2 - 4D  7.2s
> 2.082.1 - 27D 6.9s
> 2.083.0 - 45D 5.6s
> master d398d8c - 50D 4.3s
[...]
> I think we'll see even more of a gain if the D files in the backend are built all at once.
Interesting!