4 ms·

Not everyone reading your code will be using an IDE. People may be passively searching your code on GitHub/gerrit/codesearch. val/var/let/auto declarations des

Not everyone reading your code will be using an IDE. People may be passively searching your code on GitHub/gerrit/codesearch. val/var/let/auto declarations destroy the locality of understanding of a variable declaration without an IDE + a required jump-to-definition of a naive code reader. Also, a corollary of this problem also exists: if you don’t have an explicit type hint in a variable declaration, even readers that are using an IDE have to do TWO jump-to-definition actions to read the source of the variable type. eg. val foo = generateFoo() Where generateFoo() has the signature fun generateFoo(): Foo With the above code one would have to jump to definition on generateFoo, then jump to definition on Foo to understand what Foo is. In a language that requires the explicit type hint at declaration, this is only one step. There’s a tradeoff here between pleasantries while writing the code vs less immediate local understanding of future readers / maintainers. It really bothers me when a ktlint plugin actually fails a compilation because a code author threw in an “unnecessary” type hint for clarity. Related (but not directly addressing auto declarations): “Greppability is an underrated code metric”: https://morizbuesing.com/blog/greppability-code-metric/ https://morizbuesing.com/blog/greppability-code-metric/

edflsafoiewq 2y ago
If you accept f(g()), you've already accepted that the type of every expression is not written down.
- foooorsyth 2y ago
  I don’t particularly accept f(g()). I like languages that require argument labels (obj-c, swift). I would welcome a language that required them for return values as well. I’d even enjoy a compiler that injected omitted ones on each build, so you can opt to type quickly while leaning on the compiler for clarity beyond build time.
  - gpderetta 2y ago
    Argument labels are equivalent to variable names. You still have them with auto. In either case you don't see the actual type.
UebVar 2y ago
The argument is tautological. I want to use a text editor => This is the wrong tool => Yes, but I want to use a text editor. These people do use the wrong tooling. The only way to cure this grievance is to use proper tooling. The github webui has some ide features, such as symbol search. I don't see any reason why not use a proper ide. github.dev is a simple click in the ui away. When you use gerrit, do a local checkout, that's one git command. If you refuse to use the correct tools for the job, your experience is degraded. I don't see a reason to consider this case when writing code.
- foooorsyth 2y ago
  Have you ever worked in a large organization with many environments? You may find yourself with a particular interface that you don’t know how to use. You search the central code search tool for usages. Some other team IS using the API, but in a completely different environment and programming language, and they require special hardware in their test loop, and they’re located in Shanghai. It will take you weeks to months to replicate their setup. But your goal is to just understand how to use your version of the same API. This is incredibly common in big companies. If you’re in a small org with limited environments it’s less of an issue.
  - UebVar 2y ago
    I have worked in big environments. My idea about "big" might be naive, environments spanning different Oses and different, including old languages like fortran and pascal. But I never been in a situation where I couldn't check out said code, and open it in my ide and build it. If you can't that sounds like a another case of deficient tooling. Justifying deficient tooling. These where not some SWE wonderlands either. The code was truly awful at times. The Joel test is 25 years old. It's a industry standard. I, and many other people consider it a minimum requirement for software engineering. If code the "2. Can you make a build in one step?" requirement i should be ide-browsable in one step. If it takes weeks to replicate a setup the whole environment is deeply flawed. The one-step build is the second point on the list because Joel considered it the second most important thing, out of 12.
adrian_b 2y ago
I do not agree that using an IDE matters. If you cannot recognize the type of an expression that is assigned to a variable, you do not understand the program you are reading, so you must search its symbols anyway. Writing redundantly the type when declaring the variable is of no help when you do not know whether the left hand side expression has the same type. When reading any code base with which you are not familiar, you must not use a bad text editor, but either a good text editor designed for programmers or any other tool that allows fast searching for the definitions of any symbols encountered in the source text. Adding useless redundancy to the source text only bloats it, making reading more difficult, not easier. I never use an IDE, but I always use good programming language aware text editors.
chrisoverzero 2y ago
> if you don’t have an explicit type hint in a variable declaration, even readers that are using an IDE have to do TWO jump-to-definition actions to read the source of the variable type. This isn’t necessarily the case. “Go to Definition” on the `val` goes to the definition of the deduced type in the IDEs and IDE-alikes I’ve ever used.

edflsafoiewq 2y ago

If you accept f(g()), you've already accepted that the type of every expression is not written down.

foooorsyth 2y ago
I don’t particularly accept f(g()). I like languages that require argument labels (obj-c, swift). I would welcome a language that required them for return values as well. I’d even enjoy a compiler that injected omitted ones on each build, so you can opt to type quickly while leaning on the compiler for clarity beyond build time.
- gpderetta 2y ago
  Argument labels are equivalent to variable names. You still have them with auto. In either case you don't see the actual type.

UebVar 2y ago

The argument is tautological. I want to use a text editor => This is the wrong tool => Yes, but I want to use a text editor. These people do use the wrong tooling. The only way to cure this grievance is to use proper tooling. The github webui has some ide features, such as symbol search. I don't see any reason why not use a proper ide. github.dev is a simple click in the ui away. When you use gerrit, do a local checkout, that's one git command. If you refuse to use the correct tools for the job, your experience is degraded. I don't see a reason to consider this case when writing code.

foooorsyth 2y ago
Have you ever worked in a large organization with many environments? You may find yourself with a particular interface that you don’t know how to use. You search the central code search tool for usages. Some other team IS using the API, but in a completely different environment and programming language, and they require special hardware in their test loop, and they’re located in Shanghai. It will take you weeks to months to replicate their setup. But your goal is to just understand how to use your version of the same API. This is incredibly common in big companies. If you’re in a small org with limited environments it’s less of an issue.
- UebVar 2y ago
  I have worked in big environments. My idea about "big" might be naive, environments spanning different Oses and different, including old languages like fortran and pascal. But I never been in a situation where I couldn't check out said code, and open it in my ide and build it. If you can't that sounds like a another case of deficient tooling. Justifying deficient tooling. These where not some SWE wonderlands either. The code was truly awful at times. The Joel test is 25 years old. It's a industry standard. I, and many other people consider it a minimum requirement for software engineering. If code the "2. Can you make a build in one step?" requirement i should be ide-browsable in one step. If it takes weeks to replicate a setup the whole environment is deeply flawed. The one-step build is the second point on the list because Joel considered it the second most important thing, out of 12.

adrian_b 2y ago

I do not agree that using an IDE matters. If you cannot recognize the type of an expression that is assigned to a variable, you do not understand the program you are reading, so you must search its symbols anyway. Writing redundantly the type when declaring the variable is of no help when you do not know whether the left hand side expression has the same type. When reading any code base with which you are not familiar, you must not use a bad text editor, but either a good text editor designed for programmers or any other tool that allows fast searching for the definitions of any symbols encountered in the source text. Adding useless redundancy to the source text only bloats it, making reading more difficult, not easier. I never use an IDE, but I always use good programming language aware text editors.

chrisoverzero 2y ago

> if you don’t have an explicit type hint in a variable declaration, even readers that are using an IDE have to do TWO jump-to-definition actions to read the source of the variable type. This isn’t necessarily the case. “Go to Definition” on the `val` goes to the definition of the deduced type in the IDEs and IDE-alikes I’ve ever used.