Readit News logoReadit News

Deleted Comment

jffhn commented on The Vietnam government has banned rooted phones from using any banking app   xdaforums.com/t/discussio... · Posted by u/Magnusmaster
xorcist · a month ago
> The biggest "evil"

No need for the scare quotes. Forcefully removing people's agency over themselves is pretty much the definition of evil. We do not hurt criminals as punishment anymore, in the civilized age, but we still lock them up.

Now, of course we should not equate physical prisons and digital prisons in any other way, but we should absolutely call both forms of imprisonment evil, plain and simple.

jffhn · a month ago
>We do not hurt criminals as punishment anymore, in the civilized age

Singapore is quite civilized, and they conduct caning strokes.

jffhn commented on Maybe comments should explain 'what' (2017)   hillelwayne.com/post/what... · Posted by u/zahrevsky
awesan · a month ago
I feel like no one serious uses the uncle Bob style of programming anymore (where each line is extracted into its own method). This was a thing for a while but anyone who's tried to fix bugs in a codebase like that knows exactly what this article is talking about. It's a constant frustration of pressing the "go to definition" key over and over, and going back and forth between separate pieces that run in sequence.

I don't know how that book ever got as big as it did, all you have to do is try it to know that it's very annoying and does not help readability at all.

jffhn · a month ago
>where each line is extracted into its own method

As John Carmack said: "if a lot of operations are supposed to happen in a sequential fashion, their code should follow sequentially" (https://cbarrete.com/carmack.html).

A single method with a few lines is easy to read, like the processor reading a single cache line, while having to jump around between methods is distracting and slow, like the processor having to read various RAM locations.

Depending on the language you can also have very good reasons to have many lines, for example in Java a method can't return multiple primitive values, so if you want to stick to primitives for performances you inline it and use curly braces to limit the scope of its internals.

Deleted Comment

jffhn commented on The highest quality codebase   gricha.dev/blog/the-highe... · Posted by u/Gricha
gmueckl · 2 months ago
I can guarantee you that if you were to write a completely new program and continued to work on it for more than 5 years, you'd feel the same things about your own code eventually. It's just unavoidable at some point. The only thing left then is degrees badness. And nothing is more humbling than realizing that the only person that got you there is yourself.
jffhn · 2 months ago
I can guarantee you that I have been doing just that for 20 years, creating and working on the same codebase, and that it only got better with time (cleaner code and more robust execution), though more complex because the domain itself did. We would have been stuck in the accidental complexity of messy hacks and their buggy side effects if we had not continuously adapted and improved things.
jffhn commented on Trillions spent and big software projects are still failing   spectrum.ieee.org/it-mana... · Posted by u/pseudolus
graemep · 2 months ago
One of the problems is scale.

Large scale systems tend to fail. large centralised and centrally managed systems with big budgets and large numbers of people who need to coordinate, lots of people with an interest in the project pushing and lobbying for different things.

Multiple smaller systems is usually a better approach, where possible. Not possible for things like transport infrastructure, but often possible for software.

jffhn · 2 months ago
In manufacturing there are economies of scale and adding more people increases workforce, in mindfacturing there are diseconomies of scale and adding more people increases confusion, yet many managers view software with a manufacturing mindset.

Deleted Comment

jffhn commented on The Software Essays That Shaped Me   refactoringenglish.com/bl... · Posted by u/zdw
eternityforest · 4 months ago
> Test code doesn’t have its own test code

I would love it if we had better tools to make testing the tests explicit, line inline "This is what this code shouldn't do and it's a problem if there's no test that could catch it if it does" blocks.

jffhn · 4 months ago
When I do functional unit tests, they tend to include the same functional logic as the code to test. What I strive for is then to express it in a different and possibly clearer way, and I see the testing as mutual testing of two implementations, one more easily humanly checkable.
jffhn commented on If you are good at code review, you will be good at using AI agents   seangoedecke.com/ai-agent... · Posted by u/imasl42
shakna · 5 months ago
> bikeshedding function names

... Function names compose much of the API.

The API is the structure of the codebase.

This isn't some triviality you can throw aside as unimportant, it is the shape that the code has today, and limits and controls what it will have tomorrow.

It's how you make things intuitive, and it is equally how you ensure people follow a correct flow and don't trap themselves into a security bug.

jffhn · 5 months ago
Agreed. A program is made of names, these names are of the utmost importance. For understanding, and also for searchability.

I do a lot of code reviews, and one of the main things I ask for, after bug fixes, is renaming things for readers to understand at first read unambiguously and to match the various conventions we use throughout the codebase.

Ex: new dev wrote "updateFoo()" for a method converting a domain thing "foo" from its type in layer "a" to its type in layer "b", so I asked him to use "convertFoo_aToB()" instead.

jffhn commented on TODOs aren't for doing   sophiebits.com/2025/07/21... · Posted by u/todsacerdoti
lmc · 7 months ago
In my code these days, I have:

TODO

SHOULDDO

COULDDO

The TODOs generally don't make it to main, the others sometimes get picked up eventually.

jffhn · 7 months ago
I only use "TODO" eventually followed by a sub-classification like "TODO bug": it maximizes discoverability by other devs and tools, and allows for a lot of variants (both technical and/or functional) while still permitting a complete scan with a single grep.

u/jffhn

KarmaCake day364May 23, 2019View Original