Post pobrano z: Do you put anything in your code specifically for “Find in Project”?
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
Do you put anything in your code specifically for “Find in Project”? is a post from CSS-Tricks
