On Wednesday, 7 November 2018 at 00:01:13 UTC, Walter Bright wrote:
> On 11/6/2018 3:00 PM, H. S. Teoh wrote:
>> What sort of refactoring are we looking at?  Any low-hanging fruit here
>> that we non-compiler-experts can chip away at?
>
> Simply going with foreach loops is a nice improvement.

Thas sounds like a job that I can do. At this moment I am reading DMD source code starting from main() because when I tried to understand part of something I wanted to change it felt that to understand something you basically need to understand a third of compiler.

One of biggest and needless hurdle I face in reading DMD code is single letter variable name. If I change one letter variable names to more descriptive ones would that patch be welcomed or considered needless change?

On 11/7/2018 1:49 PM, welkam wrote:
> One of biggest and needless hurdle I face in reading DMD code is single letter variable name. If I change one letter variable names to more descriptive ones would that patch be welcomed or considered needless change?

Sorry, it would not be welcome. Single letter names are appropriate for locally defined symbols. There's also an informal naming convention for them, changing the names would disrupt that.

Shuffling code around without a very strong reason is also not looked upon favorably. Basically anything that vacuously creates large diffs.

On Wed, Nov 07, 2018 at 09:49:41PM +0000, welkam via Digitalmars-d-announce wrote: [...]
> One of biggest and needless hurdle I face in reading DMD code is single letter variable name. If I change one letter variable names to more descriptive ones would that patch be welcomed or considered needless change?

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.  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.

As Walter said in his recent talk, the length of variable names (or identifiers in general, really) should roughly correspond to their scope: local variable names ought to be concise, but global variables ought to be verbose (both to avoid identifier collision when a larger amount of code is concerned, and also to serve as a convenient visual indication that yes it's a global).


T

-- 
An imaginary friend squared is a real enemy.

Slides and video link:

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

On 11/7/2018 2:08 PM, 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.  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.
> 
> As Walter said in his recent talk, the length of variable names (or
> identifiers in general, really) should roughly correspond to their
> scope: local variable names ought to be concise, but global variables
> ought to be verbose (both to avoid identifier collision when a larger
> amount of code is concerned, and also to serve as a convenient visual
> indication that yes it's a global).

Yes, exactly.

On Wednesday, 7 November 2018 at 21:40:58 UTC, welkam wrote:
> On Wednesday, 7 November 2018 at 14:39:55 UTC, Joakim wrote:
>>
>> I don't know why you think that would matter: I'm using the same compilers to build each DMD version and comparing the build times as the backend was translated to D
>
> What did you compared is whether clang or DMD compiles code faster not whether D code compiles faster than C++. To check that you should compile both C++ and D with the same backend.

I'm not making any general statements about whether C++ or D compiles faster, only pointing out that in a common setup of building dmd with clang and dmd on linux/x64, I didn't see much of a speed gain. However, I did mention that the frontend should be removed to really measure the backend conversion, so that's what I just did.

I built the backends for DMD 2.080.1 through master in the same single-core VPS by slightly modifying src/posix.mak, only replacing the line "all: $G/dmd" with "all: $G/backend.a". Here are the results I got and how many D files were built in each backend:

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

So the frontend might have been obscuring things, as we see a clear win from moving the backend to D, with only about 10 C/C++ files left in the backend now and compilation time cut almost in half. I think we'll see even more of a gain if the D files in the backend are built all at once.

On 2018-11-07 23:58, Walter Bright wrote:
> Slides and video link:
> 
>   http://nwcpp.org/october-2018.html
> 
> On 11/7/2018 2:08 PM, 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.  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.
>>
>> As Walter said in his recent talk, the length of variable names (or
>> identifiers in general, really) should roughly correspond to their
>> scope: local variable names ought to be concise, but global variables
>> ought to be verbose (both to avoid identifier collision when a larger
>> amount of code is concerned, and also to serve as a convenient visual
>> indication that yes it's a global).
> 
> Yes, exactly.
> 

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.

[1] https://github.com/dlang/dmd/blob/c3dcc76327cdd1cebd9767d9ce738bcbc4db2beb/src/dmd/expressionsem.d#L3812-L4713

[2] https://github.com/dlang/dmd/blob/c3dcc76327cdd1cebd9767d9ce738bcbc4db2beb/src/dmd/expressionsem.d#L4924-L5233

-- 
/Jacob Carlborg

On Wednesday, 7 November 2018 at 22:03:20 UTC, Walter Bright wrote:
> Single letter names are appropriate for locally defined symbols. There's also an informal naming convention for them, changing the names would disrupt that.

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

because I am not proposing to change them. They are 26 times better than one letter names and changing them would not bring significant benefit. What I want to do is change variables like m. Try guessing what it is used for. Hint it is used for different things.

What I dont understand is that you are against changing variable names that would improve code understandability but you are not against changing for loops to foreach that add almost nothing to code readability and only look better.

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

On 2018-11-08 18:23, welkam wrote:


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

Changing to a foreach loop definitely adds to readability and to be able to better understand the code. If you read the "foreach" keyword you know that to a 99% possibility the code that follows is a loop that will iterate a collection from start to end. If you read the keyword "for" you basically know nothing. It can mean iterating a collection, copy some random memory or whatever.

-- 
/Jacob Carlborg

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? Ok now do the same for variable loc. See the difference?

> 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?
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

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.

> 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.

On Thursday, 8 November 2018 at 17:50:20 UTC, welkam wrote:
> On Wednesday, 7 November 2018 at 22:08:36 UTC, H. S. Teoh wrote:

> 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? Ok now do the same for variable loc. See the difference?

If we were to look for an s of a specific type, it's not just the editor we would need, now would we?

>> 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?
> 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

One keystroke (well ok, two keys because it's *) ;)
https://dl.dropbox.com/s/mifou0ervwspx5i/vimhl.png

> 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.

I don't think H.S. meant one letter vs. three. Java tends to be obtusely verbose. Wear down your fingers/eyes kind of verbose.

>> 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.

IMHO, one/two letters are fine so long as the variable's scope spans at most two pages. If scope is larger, name should be longer.