可读性和 IF 块括号:最佳实践
我正在为学习 JavaScript 基础知识的 1 级大学学生准备一个简短的教程。任务是验证电话号码。该号码不得包含非数字,且长度不得超过 14 位数字。以下代码摘录是我想出的,我希望使其尽可能具有可读性。
if (
//set of rules for invalid phone number
phoneNumber.length == 0 //empty
|| phoneNumber.length > 14 //too long
|| /\D/.test(phoneNumber) //contains non-digits
) {
setMessageText(invalid);
} else {
setMessageText(valid);
}
一个简单的问题我自己无法回答,想听听您的意见:如何定位周围(最外面的)括号?很难看出普通括号和大括号之间的区别。您通常是否将最后一个 )
与最后一个条件放在同一行?您是否将第一个开头 (
单独放在一行上?您是否也将每个单独的子条件括在括号中?您是否将第一个 (
与最后一个 < 水平对齐code>),还是将最后一个 )
与 if
放在同一列中?
是将 ) {
保留在单独的行上,还是将最后一个 )
与最后一个子条件放在同一行,然后将开头的 {换行?或者您只是将
) {
与最后一个子条件放在同一行?
社区维基。
编辑 请仅发表有关括号的使用和放置的意见。代码不需要重构。这适用于几周前才接触 JavaScript 的人。我并不是在询问如何编写代码以使其更短或性能更好的意见。我只想知道如何在 IF 条件周围放置括号。
I am preparing a short tutorial for level 1 uni students learning JavaScript basics. The task is to validate a phone number. The number must not contain non-digits and must be 14 digits long or less. The following code excerpt is what I came up with and I would like to make it as readable as possible.
if (
//set of rules for invalid phone number
phoneNumber.length == 0 //empty
|| phoneNumber.length > 14 //too long
|| /\D/.test(phoneNumber) //contains non-digits
) {
setMessageText(invalid);
} else {
setMessageText(valid);
}
A simple question I can not quite answer myself and would like to hear your opinions on: How to position the surrounding (outermost) brackets? It's hard to see the difference between a normal and a curly bracket. Do you usually put the last )
on the same line as the last condition? Do you keep the first opening (
on a line by itself? Do you wrap each individual sub-condition in brackets too? Do you align horizontally the first (
with the last )
, or do you place the last )
in the same column as the if
?
Do you keep ) {
on a separate line or you place the last )
on the same line with the last sub-condition and then place the opening {
on a new line? Or do you just put the ) {
on the same line as the last sub-condition?
Community wiki.
EDIT
Please only post opinions regarding the usage and placement of brackets. The code needs not be re-factored. This is for people who have only been introduced to JavaScript a couple of weeks ago. I am not asking for opinions how to write the code so it's shorter or performs better. I would only like to know how do you place brackets around IF-conditions.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我会将验证电话号码的逻辑重构为函数:
或者您也可以使用正则表达式来检查长度:
使用验证电话号码的函数,代码会变得更简单:
甚至:
I would refactor the logic for validating the phone number into a function:
Or you can use the regular expression to check the length also:
With a function for validating the phone number, the code gets simpler:
Or even:
tuh-MAY-toe
toe-MAH-tuh
除非有奇怪的习惯,“可读”是你习惯看到的
我会这样格式化你的示例:
因为我更喜欢看到一起解释的逻辑而不是散布在代码语句中。我喜欢将大括号单独放在一条线上,以使块更好地突出。
但是 - 正如其他人指出的 - 为了这个示例的“最终”可读性,它应该至少重构为一个 isValidPhoneNumber 函数
tuh-MAY-toe
toe-MAH-tuh
barring bizarre habits, "readable" is what you're used to seeing
i would format your example like this:
because I prefer to see the logic explained all together instead of strewn about the code statements. And I like braces on a line by themselves to make the blocks stand out better.
But - as others have pointed out - for "ultimate" readability of this example, it should be refactored into at least a
isValidPhoneNumber
function本质上,在证明有效之前无效更安全,但这完全是主观的。
在 javascript 中,also:
总是比: 更好
- 这是因为分号插入,这在这里可能不是问题,但在其他情况下可能会出现问题,因此在使用该语言时最好保持相同的习惯。
最后,我不会用比我必须的更多的括号来重载代码,特别是当事情都是“ANDed”时 - 当存在混合运算符优先级时,包含额外的括号很重要,因为不是每个人都会想要考虑阅读代码时。
但这有点主观。对不起。
essentially, invalid until proven valid is safer, but that is totally subjective.
also:
is always better than:
in javascript - this is because of semi-colon insertion, which might not be an issue right here, but could be in other cases, so it's better to maintain the same habits when working in the language.
lastly, I don't overload the code with more of this parentheses than I have to, especially when things are all "ANDed" - when there's mixed operator precedence, it's important to include the additional parentheses, because not everyone will want to think about that when reading the code.
This is all a bit subjective though. sorry.