No, no, one of the main benefits of OOP is information hiding. If your code is too greppable, developers can circumvent the information hiding.
(Sarcasm)
this post was submitted on 20 Dec 2024
92 points (98.9% liked)
Programming
17660 readers
203 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 2 years ago
MODERATORS
Using git grep os one of the most practical things I do. Whether to look for definitions, usages, or getting a list or overview of endpoints on an api, I use it for all. It's ubiquitous, works everywhere.
Yes, other tools exist that give you this information in a clear way. But the practicality of grep is amazing.
Very good points. A codebase that gets this VERY wrong is Gitlab. I think it might be a dumb characteristic of Ruby programs, but they generate identifiers all over the place. I once had to literally give up following some code because I could not find what it was calling anywhere. Insanity.
Another point: don't use - in names. Eventually you'll have to write them down in a programming language, at which point you have to change the name. CSS made this mistake. foo-bar in CSS maps to fooBar in Javascript. Rust also made this mistake with crate names. A crate called foo-bar magically becomes foo_bar in Rust code.
I've been working in Ruby on Rails lately (unfortunately) and yeah it's extremely bad at this. There's so much hidden implicit behavior everywhere.
The dash - vs underscore _ is also a common "problem" with CLI arguments --file-name, that are mapped to variable names file_name.
This is one of the reasons why I don't like short variable names, especially single letters (unless for very narrow use and obvious like i).
There was a senior dev at my first job that we called Lord Voldemort and he was the king of ungreppable variable names. Short, full of common characters, and none of them actually described what they were doing. I swear he only used characters that appeared in C++ keywords, so looking for fo would invariably tag every for statement in the file.
He also had hooks set up to notify when anyone was in his area of the code and you'd always get a two-hour phonecall where he'd slowly wear you down and browbeat you into backing out your changes. Every time I pulled a ticket in his codebase I'd internally shudder. He was friends and/or had dirt on the CTO so he just remained in that role and made everyone's life hell.
+1 for avoiding dynamically constructed identifiers when possible. Fulltext search across multiple files is available in most tools, let it be useful. It sucks having to search for a substring, hoping you guessed the way it gets constructed. Plus, it might not even occur to you that this is what you need to try.
I agree with the first point. Always go for clarity over cleverness.
I somewhat disagree with the second point. Consistency is important. Stick with the same name when possible. But I think mixing camel case and snake case should be avoided. It can make the code less ”greppable” IMO, because now you need to remember which casing was used for each variable.
Kind of agree on the third point. I think flatness should be preferred when possible and when it makes sense. Easier to find the variables with the eyes rather than having to search through nested structures.
Greppability also contributed to this thingy
int
main()
{
// dam
}
in Mozilla C-style and GNU C-style projects. Of course, it's a remnant of the past (grep ^main), but kgmgaehgka.
For code bases where this is a thing, you could use greps context lines: grep ---before-context 1 "^main"
I sort of agree with some points, especially the ones about dynamic identifier creation and renaming identifiers, but those last 2 to me sounds a lot like you don't know how to search beyond the really basic "I want this string here", I'm assuming that it's an effort to enable whoever comes next to search and find everything they should find mindlessly, not knowing the project, since the author talks about navigating foreign code bases, but I think compromises can be made when you should expect just a bit more effort from contributors for the sake of a more rationally organised code base
It's really about lowering cognitive load when making edits. It's not necessarily that someone can't figure out how to do something more sophisticated, but that they're more likely to get things right if the code is just kind of straightforwardly dumb.
The last two are definitely situational -- changing things like that might lower cognitive load for one kind of work but raise it significantly for another -- but I can see where they're coming from with those suggestions.
Even the camel/snake case renaming can be handled with the right regex, but dynamic identifiers are a mortal enemy. I remember the first time I came across a rails codebase... shudder