用于声明函数以提高可读性的模式
在 C++ 中，函数需要在调用之前声明。这可以通过函数签名来解决，但在大多数情况下，在较新的编程语言（C#、Python 等）中不再需要这样做。
然而，在阅读其他人的代码以及必须在类中构造函数时，我发现我怀念 C++ 中存在的一致性。
存在哪些模式可以声明/排序函数，同时保持代码结构的可读性和理解？
编辑 1
这是一个粗略的示例。
class A
{
private FunkB()
{
...
}
private FunkC()
{
...
}
public FunkA()
{
FunkB();
FunkC();
}
public FunkD()
{
FunkC();
...
}
}
vs
class A
{
public FunkA()
{
FunkB();
FunkC();
}
private FunkB()
{
...
}
private FunkC()
{
...
}
public FunkD()
{
FunkC();
...
}
}
Edit 2
这将是无论编辑者如何编写代码的指南。较新的编辑器具有出色的“转到定义”功能，书签也可以帮助解决这一问题。不过，我对独立于编辑器的模式感兴趣。
In C++ functions needed to be declared before they were called. This could be worked around with function signatures but for the most part this is no longer required in newer programming languages, C#, Python, ETC.
However, while reading other peoples, code and when having to structure functions in a class, I find that I miss the consistency that existed in C++.
What patterns exist to declare/order function while maintaining readability and understanding about the structure of your code?
Edit 1
Here is an rough example.
class A
{
private FunkB()
{
...
}
private FunkC()
{
...
}
public FunkA()
{
FunkB();
FunkC();
}
public FunkD()
{
FunkC();
...
}
}
v.s.
class A
{
public FunkA()
{
FunkB();
FunkC();
}
private FunkB()
{
...
}
private FunkC()
{
...
}
public FunkD()
{
FunkC();
...
}
}
Edit 2
This would be a guideline for writing code regardless of editors. Newer editors have excellent "go to definition" features and book marks help out with this too. However I'm interested in a editor independent pattern.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
当单独阅读某个方法的代码时，您想要了解该方法的意图。如果方法内部的抽象级别良好，并且所有其他调用的方法的名称在其上下文中有意义，则您不需要了解它们即可理解代码。你会把它们当作黑匣子。
一些有助于提高小代码可读性的原则：
单一抽象层原则
单一责任原则 (pdf)< /a>
组合方法
不要忘记，始终使用好名字！这就是为什么你的例子不适合这个讨论。
When reading the code of a method in isolation, you want to understand the intent of the method. If the level of abstraction inside the method is good, and the names of all other called methods make sense in its context, you won't need to know them in order to understand the code. You'll treat them like black boxes.
Some principles that help achieve greater readability in the small:
Single Level of Abstraction Principle
Single Resposibility Principle (pdf)
Composed Method
And don't forget, always use good names! That's why your example is not good for this discussion.
如前所述，对于任何像样的 IDE，文件中函数的顺序都不再是问题。对于面向对象语言来说尤其如此，其中其他导航方法比顺序读取更有用。例如：阶级等级制度；班级大纲；称之为继承制。如果您确实错过了函数定义，也许该语言中有一些东西可以满足该目的，例如：C++ 中的纯虚拟类（如果这就是它们的名称）或 Java 中的接口。
然而，话虽如此，每当我重新组织源文件中的文本时，我总是倾向于根据函数的内聚性对函数进行排序[1]。之后，我按照函数诞生的顺序进行排序。如果像您的示例一样，我有一个函数从中诞生了其他更小的辅助函数，那么我会将它们放在提取它们的位置下方。我只是发现先阅读重要的内容会更直观，然后忽略较小的细节，直到我需要了解它们，然后首先查看较大的方法通常可以实现此目的。这看起来更像你的第二个例子。
总而言之，我会选择先大后小，或者先公共再私人助手。
[1] 如果一个类/文件内有太多分组，这就是一种代码味道，建议将它们分成更小的、单独的单元。
As previously mentioned, with any decent IDE the order of functions in the file becomes much less of an issue. This is also particularly the case with object-oriented languages, where other methods of navigation are more useful than sequential reading. For example: class heirarchy; class outline; call heirarchy. If you really miss the function definitions, maybe there's something in the language that would fit that purpose instead, e.g.: pure virtual classes in C++ (if that's what they're called) or interfaces in Java.
However, having said that, whenever I'm reorganising the text in a source file, I always tend towards ordering functions based on their cohesion[1]. After that I go in the order the functions were born. If, like your example, I have a function from which other, smaller helper functions were born, I would place them below where they were extracted from. I just find it more intuitive to read what's important first, and ignoring the smaller details until I need to know them, and seeing the larger method first generally accomplishes this. This would appear to be more like your second example.
To summarise, I'd go Big then Small, or Public then private helpers.
[1] This is a a code smell if there are too many groupings within one class/file, suggesting they should be split up into smaller, separate units.
在 IDE 中，方法的顺序对我来说似乎不太重要。我不会阅读整个源代码，而是这样进行：读取一个方法，发现一个有趣的函数调用，要求 IDE 打开该函数的声明（很可能位于不同的源代码中）。或者发现一个有趣的函数，想知道它在哪里使用，请 IDE 列出引用。
IDE 通常会显示类中方法的摘要列表，并以各种方式对其进行排序和过滤，因此再次不需要端到端读取。
我真正想要的一件事是了解“这门课的用途是什么”。有两件事可以帮助做到这一点：接口编程——以及良好的类文档。
因此，我鼓励明确记录类的职责，通常以特定接口的形式表达。源代码中方法的顺序对我来说不太重要。
In an IDE the order of the methods seems to matter much less to me. I don't read the whole source, rather I proceed like this: read a method, spot an interesting function call, ask IDE to open declaration of that function (which may well be in a different source). Or find an interesting function, wonder where it's used, ask the IDE to list the references.
The IDE usually displays a summary list of the methods in a class, and sorts it and filters it in various ways, so once again the end-to-end read is not needed.
The one thing I do want is a "what's this class for" understanding. There's two things that help with that: Programming to Interfaces - and good class documentation.
So I would encourage clearly documented responsibilities for the class, often expressed in terms of specific Interfaces. The order of methods in the source is less important to me.