是否有制作人类可读代码的基本标准和实践?

发布于 2024-09-24 22:03:08 字数 55 浏览 9 评论 0原文

更具体地说,是让 HTML、Java 和 python 更具可读性?有人对这个编程学生有建议吗?

More specifically making HTML, Java, and python more readable? Does anyone have suggestions for this programming student?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(9

温柔一刀 2024-10-01 22:03:08
  1. 使用一致的大小写和命名。

  2. 使用制表符(以及可用的括号)提供视觉流程。

  3. 使用注释来解释概念上和技术上发生的事情。 (例如, //Do we have a valid user? not //Check that user_ID is not -1)

我确信一些经验丰富的开发人员会有更多建议,但这些是我的前 3 条建议。

  1. Use consistent casing and naming.

  2. Use tabs (and brackets where available) to provide a visual flow.

  3. Use comments that explain what's happening conceptually as well as technically. (e.g., //Do we have a valid user? not //Check that user_ID is not -1)

I'm sure some more seasoned developers will have more suggestions, but those are my top 3.

白昼 2024-10-01 22:03:08

适当的缩进和信息丰富的注释。

Proper indention and informative comments.

酒浓于脸红 2024-10-01 22:03:08

使用缩进、注释和编码约定(对于 Python,请检查 PEP8

Use indentation, comments and coding conventions( for Python check PEP8 )

執念 2024-10-01 22:03:08

确保您的代码结构良好(正确的缩进、用于分隔代码部分的空行等)并使用标准、一致且完整命名(而不是难以理解的缩写)的变量名称。

其他人会建议使用适当的注释。我倾向于不同意。如果您的代码结构良好并且变量命名良好,那么注释只会使事情变得混乱。该规则的例外是,当您必须做一些违反直觉的事情来解决其他地方的错误时(我过去不得不在 WCF 和实体框架代码中诉诸于此)。

Make sure your code is well structured (proper indentation, blank lines to separate sections of code, etc.) and use standard, consistent, and fully named (rather than incomprehensible abbreviated) variable names.

Others would suggest using proper comments. I would tend to disagree. If your code is well structured and variables well named, then comments would just clutter things up. The exception to the rule being when you must do something counter-intuitive to work around a bug somewhere else (I've had to resort to this in WCF and Entity Framework code in the past).

初雪 2024-10-01 22:03:08

尝试大声朗读您的代码(或者至少在您的脑海中)。

Try to read your code out loud (or at least in your head).

深爱成瘾 2024-10-01 22:03:08

看看这本书:《干净的代码:敏捷软件工艺手册》 。这一切都是为了使代码可读且易于理解。

Have a look at this book: Clean Code: a handbook of agile software craftsmanship. It is all about making code readable and understandable.

疯狂的代价 2024-10-01 22:03:08

一个建议是不要在名字上偷懒。例如,如果您有一个 Java 类,它是 Transformer 接口的实现,并且它将 String 转换为 Date,请毫不犹豫地将类命名为 StringToDateTransformerImpl。

One piece of advice is not to be lazy with names. For example, if you have a Java class which is an implementation of the Transformer interface, and it transforms String to Date, don't hesitate to name the class StringToDateTransformerImpl.

清秋悲枫 2024-10-01 22:03:08

好吧,你总是可以使用“无知测试”。向对编程一无所知的人展示您的代码。如果他或多或少能看到函数的作用,那么代码可能是可读的。

Well, you can always use the "ignorant test". Show your code to someone who knows absolutely nothing about programmation. If he can see more or less what a function does, the code is probably readable.

明月夜 2024-10-01 22:03:08

编写 HTML 时正确的缩进可以成为救星,尤其是在与任何类型的嵌套元素交互时。只需与缩进保持一致,并确保在移动或删除缩进元素时更新周围的行。这使得更新页面变得更加容易,因为缩进级别将提供有关您在页面中的位置的线索,而无需诉诸某种 Ctrl+F 操作。

还值得注意的是,如果您将 CSS 与 HTML 结合使用,正确的命名至关重要!它将改善您的工作流程和代码的可读性。

在编写“真实”(Java、Python、C 等)代码时,我也非常喜欢缩进、间距和注释。我倾向于 (x + 1) 而不是 (x+1),因为我个人认为它在可读性上有很大的不同。我将演员表、增量等间隔开来,它们更容易引起我的注意。与您的括号/缩进风格保持一致,并自由地进行注释 - 请记住,重写方法名称不是注释!

Proper indentation when writing HTML can be a lifesaver, especially when you're interacting with any sort of nested elements. Just be consistent with the indentation and be sure to update surrounding lines when you move or delete an indented element. This makes it much easier to update the page, as the level of indentation will give a clue as to where you are in the page without resorting to some sort of Ctrl+F maneuver.

It's also worth noting that if you're using CSS in conjunction with HTML, proper naming is critical! It will improve your workflow and the readability of your code.

I'm also a big fan of indentation, spacing, and comments when writing "real" (Java, Python, C, etc.) code. I lean towards (x + 1) over (x+1) because I personally think it makes a big difference in readability. I space out casts, increments, etc. and they catch my eye much more easily. Be consistent with your bracket/indentation style, and comment liberally - remember, re-writing a method name is not a comment!

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文