During a having a team meeting the other day, a code formatting idea came up that I thought was super interesting. It had to do with formatting code in a such a way that made it easier to find what you were looking for later with any code editors “Find in Project” feature.
Here’s what it was.
When declaring a function in JavaScript, put a space after the function name and before the opening parenthesis, like…
function doSomething () {
}
That space between doSomething
and ()
is perfectly fine. Then when you call the function, don’t use a space, like this:
doSomething();
It’s just a syntax convention.
But now, “Find in Project” is more useful. If we want to quickly find where that function was defined, we can search for “doSomething ()”, and if we want to find instances of where it is used, we can look for “doSomething()”.
You could extend the idea to classes or whatever too:
class myThing {
constructor () {
}
doThing () {
}
}
let example = new myThing();
example.doThing();
I’d say that’s worth doing.
It reminds me of when I need to where a Ruby method is definied, I can always search for “def foo” since that “def ” is required for creating the method.
I can imagine a scenario where it might be useful to define base classes in CSS like .module {
but then if it’s a variation or nested or used again for any other reason… .module{
.
Here’s a classic:
// TODO: 😅
— Charlotte Dann (@charlotte_dann) September 10, 2017
Leaving TODO comments throughout your code base turns a “Find in Project” for “TODO” an instant list of things you need to work on. Surely that could be even more nuanced, incorporating things like priority levels and assignments. Perhaps even emoji’s to help like Charlotte suggested!
Here’s an interesting one:
Use long classes/variables, mark future refactor points with comments. What are you looking for?
— Chris Pauley (@ChrisPauley) September 10, 2017
I like the idea of “long names”. I suppose the longer and more descriptively you name things, the easier they are to search for and get specific results (avoiding repetitive matches like you would with very simple names).
Comments are a great place to leave things to search for. I often use a convention where I put my own name in the comment if I want people to know it was me leaving the comment, but it’s not necessarily for me.
.thing {
overflow: hidden; /* [Chris]: ugkghk this fixed a layout thing but I didn't have time to figure out exactly why. */
}
A smattering of responses:
At top of each template I add "<!– Start [name of template] –>", at bottom, same but "End." Helps FIP and in browser-rendered code.
— Dale Henry Geist (@dalehenrygeist) September 10, 2017
I use consistent and natural language to name things, so when documentation goes stale, at least the code itself is still easy to stab at.
— John James Jacoby (@JJJ) September 10, 2017
Not in the code itself but in Sublime settings folder_exclude_patterns you can pass in an array of folders to exclude from all searches
— Ian C Woodward (@IanCWoodward) September 10, 2017
// TODO 😕
// FIXME 😲
// WT* 😤💣— Kamran Ahmed (@kamranahmedse) September 10, 2017
ctags is a lifesaver.
— Harry Roberts (@csswizardry) September 10, 2017
Naming conventions mate! BEM-esque those classes up `–thing` is always easier to find than `thing`
— James Bosworth (@fltwhte) September 11, 2017
I have a long running habit of searching for “ion daFunction” when I want the function definition only, which covers this need already. To me the space before parenthesis looks kinda “broken”, even though I know it’s fine. But I could get used to it.
I use
/* @TODO: */
and/*@FIXME: */
messages, so in the git-repository possible commits with messages like “Fixed|wontfix #4”.Eh, isn’t that StandardJS syntax? If you enforce that through ESLint or similar it’ easy. Never thought of using it for “Find in project”, useful!
The goal is worthwhile and the technique is one way to accomplish the goal.
The basic way to get what you’re looking for without worrying about this kind of a coding convention is to be (debatably) tricky with your search key
search = “.doSomething” when you are seeking invocations.
search = “on doSomething” when you’re seeking the declaration. (where “on” are the final 2 characters of the word function)
The only important thing of note is that your team is in agreement with whatever approach you choose.
You know searching for “n functionname” or “s classname” works just as well and doesn’t require a strange whitespace habit ;)
Also functions could be in object literals, or is that no longer a thing in your codebase?
Choosing names that are git grep’able is something I do for a long time already and find super useful especially across language boundaries.
What’s wrong with using an IDE instead of Sublime and using the “go to definition” feature of a method call?
I guess nothing… unless you prefer using Sublime rather than an IDE :)
Second this. Any decent IDE has this feature for supported languages. No need to get hacky with code formatting, when the editor understands your code.
Enrique Moreno, if you’re serious about writing code, it seems like a no-brainer to use an IDE. Using Sublime is like becoming a carpenter but refusing to use power tools. Walking through code, inspecting method implementations and definitions, all of this is just so easy with an IDE. I don’t understand why anyone would intentionally hobble themselves with something which just doesn’t offer the features a serious developer needs.
You don’t need any IDE, Atom and VS Code can do that already (the latter actually working quite well out of the box).
I have a coworker that likes to destructure React props inside the
render()
function (var { prop1, prop2 } = this.props;
) for brevity, but I refuse to, partly for this reason. If I need to find every reference to some prop (or state variable for that matter), I can search forthis.props.foo
and know that I’ve found exactly every single usage, and nothing else.What exactly does Harry Roberts mean with ctags?
This:
https://andrew.stwrt.ca/posts/vim-ctags/
@Tim https://en.wikipedia.org/wiki/Ctags
Code rules are fine until you miss that one declaration which accidently got misformed. Don’t trust the code formatting, ever!
If you really want to find everything using flat grep tech, just learn regex.
Love the idea of the space in the function definition…
Things like this are exactly why TypeScript is taking off and is so useful.