• 0 posts
  • 7 comments
Joined 2 years ago
Cake day: May 20th, 2024
  • One example for self documenting code is typing. If you use a language which enforces (or at least allows, as in Python 3.8+) strong typing and you use types pro actively, this is better than documentation, because it can be read and worked with by the compiler or interpreter. In contrast to documenting types, the compiler (or interpreter) will enforce that code meaning and type specification will not diverge. This includes explicitly marking parameters/arguments and return types as optional if they are.

    I think no reasonable software developer should work without enforced type safety unless working with pure assembler languages. Any (higher) language which does not allow enforcing strong typing is terrible.

  • I have worked on larger older projects. The more comments you have, the larger the chance that code and comment diverge. Often, code is being changed/adapted/fixed, but the comments are not. If you read the comments then, your understanding of what the code does or should do gets wrong, leading you on a wrong path. This is why I prefer to have rather less comments. Most of the code is self a explanatory, if you properly name your variables, functions and whatever else you are working with.

  • Syncthing on Android has an option to only sync when on AC battery. The PC client might have a similar option. If not, you could probably configure something similar via systemd or udev under Linux.

    I don’t think syncthing has proper means to synchronize contacts or anything else that’s not file-based though.

    I use syncthing and prefer it for synchronizing files between my devices.