前几天,在一次团队会议中,我们提出了一个代码格式化想法,我认为它非常有趣。 它与以这样一种方式格式化代码有关,即使用任何代码编辑器的“在项目中查找”功能更容易找到要查找的内容。
以下是内容。
在 JavaScript 中声明函数时,在函数名称后和左括号前添加一个空格,例如…
function doSomething () {
}
doSomething 和 () 之间的空格完全没问题。 然后,当您调用函数时,不要使用空格,像这样
doSomething();
这只是一个语法约定。
但现在,“在项目中查找”更有用。 如果我们想快速找到定义该函数的位置,我们可以搜索“doSomething ()”,如果我们想找到使用该函数的实例,我们可以查找“doSomething()”。
您也可以将该想法扩展到类或其他任何内容。
class myThing {
constructor () {
}
doThing () {
}
}
let example = new myThing();
example.doThing();
我认为值得这样做。
它让我想起当我需要查找 Ruby 方法的定义时,我总是可以搜索“def foo”,因为“def ”是创建该方法所必需的。
我可以想象这样一种情况,在 CSS 中定义基本类可能很有用,例如 .module {,但如果它是变体或嵌套的,或者出于任何其他原因再次使用… .module{。
这是一个经典示例
// TODO: 😅
— Charlotte Dann (@charlotte_dann) 2017 年 9 月 10 日
在整个代码库中留下 TODO 注释,将“在项目中查找”用于“TODO”变成一个即时的待办事项列表。 当然,这甚至可以更加细致,包含诸如优先级级别和分配之类的内容。 也许还可以像夏洛特建议的那样,使用表情符号来帮助!
这是一个有趣的示例
使用长类/变量,用注释标记未来的重构点。 你在找什么?
— Chris Pauley (@ChrisPauley) 2017 年 9 月 10 日
我喜欢“长名称”的想法。 我想,名称越长,描述越详细,就越容易搜索和获得特定结果(避免像使用非常简单的名称那样重复匹配)。
注释是放置要搜索内容的好地方。 我经常使用一种约定,如果我想要让人们知道是我留下了注释,我会在注释中加上自己的名字,但这并不一定是针对我自己的。
.thing {
overflow: hidden; /* [Chris]: ugkghk this fixed a layout thing but I didn't have time to figure out exactly why. */
}
一些回复
在每个模板的顶部,我添加“<!– Start [模板名称] –>”,在底部添加相同的内容,但改为“End”。 这有助于 FIP 和浏览器渲染的代码。
— Dale Henry Geist (@dalehenrygeist) 2017 年 9 月 10 日
我使用一致的自然语言为事物命名,因此当文档过时时,至少代码本身仍然很容易上手。
— John James Jacoby (@JJJ) 2017 年 9 月 10 日
不在代码本身中,而是在 Sublime 设置的 folder_exclude_patterns 中,您可以传入一个要从所有搜索中排除的文件夹数组。
— Ian C Woodward (@IanCWoodward) 2017 年 9 月 10 日
// TODO 😕
// FIXME 😲
// WT* 😤💣— Kamran Ahmed (@kamranahmedse) 2017 年 9 月 10 日
ctags 是一个救星。
— Harry Roberts (@csswizardry) 2017 年 9 月 10 日
命名约定,伙计! BEM 风格的那些类
–thing总是比thing更容易找到— James Bosworth (@fltwhte) 2017 年 9 月 11 日
我一直有一个习惯,当我只需要函数定义时,我会搜索“ion daFunction”,这已经涵盖了这个需求。 对我来说,左括号前的空格看起来有点“断裂”,即使我知道这是可以的。 但我可以慢慢习惯它。
我使用
/* @TODO: */和/*@FIXME: */消息,因此在 git 存储库中,可能会有类似“Fixed|wontfix #4”的提交消息。嗯,这不是 StandardJS 语法吗? 如果您通过 ESLint 或类似工具强制执行它,就很容易。 从未想过将其用于“在项目中查找”,这很有用!
目标是值得的,而且该技术是实现目标的一种方式。
无需担心这种编码约定,获得所需内容的基本方法是(可以争论)使用技巧进行搜索
搜索 = “.doSomething” 时,您正在寻找调用。
搜索 = “on doSomething” 时,您正在寻找声明。(其中“on”是“function”一词的最后两个字符)
需要注意的唯一重要事项是,您的团队同意您选择的任何方法。
您知道搜索“n functionname”或“s classname”效果一样好,而且不需要奇怪的空格习惯;)
另外,函数可能在对象文字中,或者这在您的代码库中不再是问题了吗?
选择可以进行 git grep 的名称是我很久以前就做的事情,而且我发现它非常有用,尤其是在跨语言边界时。
使用 IDE 而不是 Sublime 并使用方法调用的“转到定义”功能有什么问题呢?
我认为没有问题… 除非您更喜欢使用 Sublime 而不是 IDE :)
我同意。 任何像样的 IDE 都为支持的语言提供了此功能。 无需对代码格式进行繁琐的修改,因为编辑器可以理解您的代码。
Enrique Moreno,如果您认真对待编写代码,那么使用 IDE 似乎是明智之举。 使用 Sublime 就像成为一名木匠,但拒绝使用电动工具。 浏览代码,检查方法实现和定义,所有这些使用 IDE 都非常容易。 我不明白为什么任何人会故意使用不提供严肃开发人员所需功能的东西来阻碍自己。
您不需要任何 IDE,Atom 和 VS Code 已经可以做到(后者实际上开箱即用,工作得很好)。
我有一个同事喜欢在
render()函数(var { prop1, prop2 } = this.props;)中解构 React 道具,以简化代码,但我拒绝这样做,部分原因是出于这个原因。 如果我需要找到对某个道具(或状态变量)的所有引用,我可以搜索this.props.foo,并且知道我找到了所有用法,而没有其他内容。Harry Roberts 使用 ctags 的确切含义是什么?
这个
https://andrew.stwrt.ca/posts/vim-ctags/
@Tim https://en.wikipedia.org/wiki/Ctags
代码规则很好,直到您错过了一个意外格式错误的声明。 不要相信代码格式,永远不要!
如果您真的想使用简单的 grep 技术找到所有内容,那就学习正则表达式吧。
喜欢函数定义中的空格这个想法…
正是因为这样的事情,TypeScript 才会如此流行,而且非常有用。