Oddbean new post about | logout
▲ ▼
mleku | 4 months ago (raw) | root | parent | reply | flag +3 
 yeah, you would only learn such things by building the base level parsing code clean to discover this if you weren't following all the chaotic goings on in the repo
▲ ▼
Laeserin | 4 months ago (raw) | root | parent | reply | flag 
 Literally everything. The specs are often not self-explanatory. 

Npubs should be able to just fork, add what they just learned, the others with a merge request, and move on with their lives.
▲ ▼
Laeserin | 4 months ago (raw) | root | parent | reply | flag 
 GN 😴
▲ ▼
Laeserin | 4 months ago (raw) | root | parent | reply | flag +1 
 One more thing

Write coding guidelines for the specs. Then rewrite all existing specs to match them, as close as possible.

Then you don't have to have senior engineers saying "No json in the content field" or "make sure to use asciidoc or markdown compatible with asciidoc" to every new entrant.
▲ ▼
mleku | 4 months ago (raw) | root | parent | reply | flag +1 
 yes, coding guidelines help a lot

i have some unusual preferences in that for my own projects because i get intensely curious about neat things i see... like, almost nobody else except a few smart guys know that you can do one line functions in Go, or that you can break lines after dot operators, and my current little thing is using a script to drop a "common" file into every package that gives you lots of handy type aliases and a few common functions that you can update just by changing one version and running a script

like, why would i type []byte when i could just use B

and in local scopes, who uses B anyway? that's an exported variable name, in a local scope? yes! that's the point, you aren't going to mistake it and why write []byte when you can write B!

it also injects loggers and such into the code, and honestly i think it would be a great feature in Go if you could write one file at the root of a repo that automatically is part of every package for this kind of stuff, it's not a macro system, it's aliases, and the aliases make the code more readable and easier to type

anyway, going off track, but JSON doesn't forbid JSON inside strings except that the quotes have to be escaped, pretty much, probably some shortcuts can be taken for this... as it is, i already experimented with this because tags are "free form" but there is a whole bunch of rigid structures defined and in many cases they use hex encoding which is automatically double the binary version and for runtime why the fuck deal in encodings when you match faster on the binary and if the binary is what your database uses???

but it's work that i'm doing because of my own personal distaste for convention and love of elegance and conciseness

in my own work, this leads to me recognising bugs in my code faster because i spend less time ignoring fluff and more time actually understanding the code

there is some hilarious morons who like to chant "the code is the documentation" but you read their code and it's like reading beat poetry, good luck making sense of it, and the time it takes for the compiler to turn it into assembler... that's a big hint that the code is unclear