4 ms·

>Look for coding conventions that make wrong code look wrong. Or code more readable, and more obviously right or wrong. A few I use : - always suffix with th

by jffhn 4y ago

>Look for coding conventions that make wrong code look wrong. Or code more readable, and more obviously right or wrong. A few I use : - always suffix with the unit, for quantities for which we are likely to not always use SI units (ex.: time ("double timeS" for physics, "long timeNs" for low level scheduling, etc.), angles (latRad, latDeg, etc.)) - lists/sets of Foo named fooList/fooSet by default (or xxxFooList, etc) - Map<Foo,Bar> : barByFoo - Foo[] : fooArr - return value : ret (some use "result", but it's longer to type/read, "ret" is more obviously related to "return", and a result can just be intermediate and not something to return)

ncmncm 4y ago
barByFoo is a very good convention when there is, as often, only one. The others, not so much. It might be a set today, but not tomorrow. Degrees is a good type for variables you keep degrees in.
- jffhn 4y ago
  We don't want to be too abstract, to get a feel for what we are doing, especially for collections and their different and possibly touchy algorithmic complexities, but if it makes sense we can use fooColl to reference a set as a general collection, for parts of the code that work well with any collection.
  - ncmncm 4y ago
    I have seen "fooz" used for that, the "z" to disambiguate from "foos" that might be a numeric count of foo.
cpeterso 4y ago
> return value : ret Fun fact: Rust's return keyword was originally spelled "ret" (because, IIUC, Rust designer Graydon wanted all keywords to be <= 5 characters). Enough people complained that "ret" was too ugly and unnecessarily breaking precedent from other languages, so it was changed to "return". I don't like "ret" because makes me think of "retch" :) but you make a good argument for using it for return values. Mozilla's coding style typically uses "rv".
- ncmncm 4y ago
  Every language that survives becomes a legacy language full of might-have-beens.
- layer8 4y ago
  I still can’t get over “mut”.
JohnBooty 4y ago
always suffix with the unit Heck yeah. One of the few things in this godforsaken industry/craft that I consider to be unambiguously true. for quantities for which we are likely to not always use SI units Do you mean "likely to not always use SI base units?" Second and millisecond are, for example, both SI units. Regardless, I think it's worth suffixing all variables with unit type regardless of SI base units or not. This is particularly true for large and/or long lived projects with multiple developers. Developers are almost always the limiting factor in any development effort. Therefore, always prioritize reduction of developers' cognitive load unless there is some specific reason not to (ie unrolling a loop for performance reasons, etc) The only arguments against longer identifier names are non-issues: 1. "They're harder to type." If you're using a code editor without autocomplete in 2022, that's on you. 2. "If I use long identifier names I can't fit as much code on a line." Bit of a coding style smell if this is an issue, IMO.
- jffhn 4y ago
  Yes, SI base, for example second, not powers of tens of it, but we just call it SI. For linear positions no suffix means meters (x, y, z, etc.), same vx is in m/s etc. Autocomplete is nice but in my IDE it requires hitting ctrl+space and then you might have a choice to make.
  - wizofaus 4y ago
    Linear positions with no suffix I'd typically assume were in pixels! Or just unitless cartesian positions.
    - jffhn 4y ago
      All the domain revolves around things moving around in the real world, there is no pixel. Also at some point, to prevent unit problems, someone tried to add methods for units handling (set value and unit, get value for unit, or get value and unit separately), but it was a train wreck (people setting with fancy units, people getting the raw value assuming SI, and when unit was properly specified to the getter much time was spent in the object oriented and allocation addict units framework, and the code was bloated with units condiderations), so we got rid of that (which could surely be done better, but we thought it was just better without. We just have a few utility functions on the side for the rare cases where we need units conversions).

by jffhn 4y ago

ncmncm 4y ago

barByFoo is a very good convention when there is, as often, only one. The others, not so much. It might be a set today, but not tomorrow. Degrees is a good type for variables you keep degrees in.

jffhn 4y ago
We don't want to be too abstract, to get a feel for what we are doing, especially for collections and their different and possibly touchy algorithmic complexities, but if it makes sense we can use fooColl to reference a set as a general collection, for parts of the code that work well with any collection.
- ncmncm 4y ago
  I have seen "fooz" used for that, the "z" to disambiguate from "foos" that might be a numeric count of foo.

cpeterso 4y ago

> return value : ret Fun fact: Rust's return keyword was originally spelled "ret" (because, IIUC, Rust designer Graydon wanted all keywords to be <= 5 characters). Enough people complained that "ret" was too ugly and unnecessarily breaking precedent from other languages, so it was changed to "return". I don't like "ret" because makes me think of "retch" :) but you make a good argument for using it for return values. Mozilla's coding style typically uses "rv".

ncmncm 4y ago
Every language that survives becomes a legacy language full of might-have-beens.
layer8 4y ago
I still can’t get over “mut”.

JohnBooty 4y ago

always suffix with the unit Heck yeah. One of the few things in this godforsaken industry/craft that I consider to be unambiguously true. for quantities for which we are likely to not always use SI units Do you mean "likely to not always use SI base units?" Second and millisecond are, for example, both SI units. Regardless, I think it's worth suffixing all variables with unit type regardless of SI base units or not. This is particularly true for large and/or long lived projects with multiple developers. Developers are almost always the limiting factor in any development effort. Therefore, always prioritize reduction of developers' cognitive load unless there is some specific reason not to (ie unrolling a loop for performance reasons, etc) The only arguments against longer identifier names are non-issues: 1. "They're harder to type." If you're using a code editor without autocomplete in 2022, that's on you. 2. "If I use long identifier names I can't fit as much code on a line." Bit of a coding style smell if this is an issue, IMO.

jffhn 4y ago
Yes, SI base, for example second, not powers of tens of it, but we just call it SI. For linear positions no suffix means meters (x, y, z, etc.), same vx is in m/s etc. Autocomplete is nice but in my IDE it requires hitting ctrl+space and then you might have a choice to make.
- wizofaus 4y ago
  Linear positions with no suffix I'd typically assume were in pixels! Or just unitless cartesian positions.
  - jffhn 4y ago
    All the domain revolves around things moving around in the real world, there is no pixel. Also at some point, to prevent unit problems, someone tried to add methods for units handling (set value and unit, get value for unit, or get value and unit separately), but it was a train wreck (people setting with fancy units, people getting the raw value assuming SI, and when unit was properly specified to the getter much time was spent in the object oriented and allocation addict units framework, and the code was bloated with units condiderations), so we got rid of that (which could surely be done better, but we thought it was just better without. We just have a few utility functions on the side for the rare cases where we need units conversions).