代码布局提示？ [英] Tips on code layout?

问题描述

我正在创建一个事务处理系统，所以它涉及大量的验证，到目前为止我已经编写了2000行代码，并且越来越难以跟踪事物。



您在编程时如何使代码更易读和组织[以便更快地导航]有哪些提示？

I am creating a Transaction Processing System, so it involves a lot of validations and so far I've written 2000 lines of codes and it's getting harder to keep track of things.

What are your tips on how to make code more readable and organized [for faster navigation as well] when programming?

推荐答案

第1步 - 分解将代码转换为更小的函数/方法



步骤2 - 将类似的函数组合在一起，例如所有加载方法，搜索方法等，并将它们放在一个区域中的区域中一种可以折叠的分组技术。您可以使用以下语法开始和结束区域

Step 1 - break down your code into smaller functions / methods

Step 2 - group your similar functions together for example all load methods, search methods etc, and place them in a region a region is a grouping technique which can be collapsed. You start and end a region using the following syntax

#region [Name of Region]
 *// enter code here.
#endregion

第3步 - 缩进你的正确的代码，这使得查看大型函数时更容易，看看哪些代码嵌套在if / while等语句中

Step 3 - indent your code correctly, this makes it much easier when looking at large functions, to see which code is nested inside if / while etc statements

这个主题太大而无法涵盖所有​​方面。此外，人们对可读性和维护有不同的看法，因此提出两个严格的要求并不是很好。更重要的是，你可以在一个团队中工作，所有成员都希望看到整洁的代码（与那些没有代码的人合作可能太难）但对如何格式化代码有不同的看法，所以我的第一个建议是我的规定是为了解决这个有时候很痛苦的问题。



关键是C＃特有的。对于此语言，Visual Studio（某些备用IDE具有等效功能）详细的自动格式化规则在选项中定义。使用这些规则。您可以修改它们，但保持格式一致。良好格式化的标准是：如果您剪切所有代码并粘贴它，自动格式化将导致完全相同的代码格式。现在，如何处理不喜欢您的选项的不同团队成员？我提出了以下规则：最后一次格式化代码的人总是对的。不喜欢你同事的格式化？重新格式化你的味道，但只能自动。如果您进行任何更改，请使用您的格式提交它们;之后使用您的代码的人可以把它变成一个人的喜好。如果您不进行更改，只需阅读，根据自己的喜好重新格式化，阅读所有您需要的内容，但不要提交更改。 （在本段中，我假设你总是使用一些修订控制系统。甚至不使用没有这样的系统工作的想法;这意味着你根本不做编程，因为你宝贵的编程断言不属于你，但是第一次意外或只是人为错误。）



不幸的是，自动格式化并不涵盖所有方面。关于免费格式化功能是空白行。我建议制定关于它们的严格规则，但这取决于你。



然后，有很多与格式无关的方面。其中一个是评论。我不能写太多关于它的内容，但它需要对这些想法进行大量解释。所以，我只想给你一个想法：代码应该是自我评论。现在，命名。我强烈建议使用Microsoft命名约定。但是这个建议并不涵盖命名的所有方面，这是整个艺术。只是培养良好的品味。



但最大的问题远不止格式化，命名和评论。其中大部分都在代码中。很难提出一些肯定的建议，因为想法的数量非常大，即使我只计算自己的想法。本主题是接近通用代码架构和设计，以认真讨论任何事情。但我会列出几个快速点。



密切关注部分类并放入不同的文件。有时我使用具有相同文件名的文件，但在不同的目录中。相同名称的文件具有相同类的不同部分。这样，您可以分隔不同的方面。例如，目录Model和目录Model.Binding中的两个不同文件ParsingRules.cs。在第一个目录中的一个文件中，您具有某些类的主要部分，而在另一个目录中的另一个文件中，您具有某些相同类的其他部分以及实现绑定的方法。等等。另外，请注意匿名方法。在一种情况下是好的而在另一种情况下是坏的。好吧，我已经开始谈论代码设计了。考虑不同的选择并在单独的帖子中提出您的问题。您的问题涉及的所有主题都可以成为一本大书。无论如何，也许主要的建议是：通过一切方式避免硬编码的立即常量，更好地声明显式常量或使用资源。永远不会有神奇的话语。 不要重演 。



什么是好代码？好吧，尝试用你在3个月前，2年前开发的困难解决方案来阅读代码...你能快速找到解决类似问题的方法吗？如果是的话，我的祝贺。什么，你的同事开始对你的代码说同样的话？这很难相信，但事实确实如此，是时候制作你的肖像，加上伟大的可读性大师，框架并交给办公室。祝你好运。

-SA

This topic is too big to cover all aspects. Besides, people have different views on readability and maintenance, so it would be not very good to give two stiff requirements. More to this, you can work in a team where all members want to see neat code (it can be too hard to work with those who don't) but have different views on how to format the code, so my first advice would be my provisions I made to address this sometimes painful problem.

The key is specific to C#. For this language, Visual Studio (some alternative IDE have equivalent features) detailed auto-formatting rules are defined in the options. Use those rules. You can modify them, but keep formatting consistent. The criteria for good formatting is: if you cut all code and paste it, auto-formatting will result in exact same code formatting. Now, what to do with different team members who don't like your set of options? I put forward the following rule: the one who formatted the code for the last time is always right. Don't like formatting of your colleague? Reformat it to you taste, but only automatically. If you do any changes, commit them using your formatting; the one who use your code later can turn it to one's liking. If you don't do changes, just reading, reformat it to your liking, read all you need, but don't commit the changes. (In this paragraph, I assume you always use some Revision Control System. Don't even play with the idea of working without such system; it would mean that you are not doing programming at all, because your valuable programming assert would not belong to you, but to the first accident or just a human mistake.)

Unfortunately, auto-formatting does not cover all aspects. On of the "free" formatting features is the blank lines. I would advise to develop strict rules about them, but it's up to you.

And then, there are a lot of aspects not related to formatting. One of them is commenting. I cannot write too much about it, but it needs a lot of explanation of the ideas. So, I would leave you with just one idea: code should be self-commenting. Now, naming. I would strongly advise to use Microsoft naming convention. But this advice does not cover all aspects of naming, which is the whole art. Just develop good taste.

But the biggest problems go well beyond the formatting, naming and commenting. Most of them are in the code in general. It's very hard to advise something certain, because number of ideas is quite big, even if I counted only my own ones. This topic is to close to general code architecture and design to discuss anything seriously. But I'll list just few quick points.

Pay close attention for partial classes and putting part in different files. Sometimes I use files with identical file names, but in different directories. The files of identical names have different parts of the same classes. This way, you can separate different aspects. For example, two different files "ParsingRules.cs" in the directory "Model" and in the directory "Model.Binding". In one file in first directory you have main parts of some class(es), and in another file in another directory you have other parts of some of the same classes with methods implementing binding. And so on. Also, pay attention for anonymous methods. The are good in one cases and bad in others. All right, I am already sorry that I started to talk about the code design. Consider different alternatives and ask your questions in separate post. All topics involved in your question can make a big book. Anyway, perhaps the main advice will be: avoid hard-coded immediate constants by all means, better declare explicit constants or use resource. No "magic words", ever. Don't repeat yourself.

What is good code? Well, try to read the code with the difficult solution you developed 3 months ago, 2 years ago… Can you quickly find out how to solve the similar problem looking at your old code? If so, my congratulations. What, your colleagues started to say the same about your code? This is hard to believe, but it this is really so, it's time to make your portrait, add the words "Great Readability Master", frame it and hand in the office. Wish you the best of luck.

—SA

这篇关于代码布局提示？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！