Anyone else find naming classes and methods one of the most difficult parts in programming?
所以我正在处理这个类，这个类应该通过Web服务向供应商请求帮助文档。我试着把它命名为
开始用不好的名字编程就像早上头发很糟糕，剩下的一天就从那里开始走下坡路。摸摸我？
您现在所做的一切都很好，我强烈建议您坚持当前的语法，即：
上下文+动词+如何
我使用此方法命名函数/方法、SQL存储过程等。通过使用此语法，它将使您的IntelliSense/代码窗格更加整洁。所以您需要employeeGetByID()employeeAdd()，employeeDeleteByID()。当您使用更加语法正确的语法(如getEmployee()、addEmployee())时，您会发现，如果同一类中有多个get，则会非常混乱，因为不相关的东西将被分组在一起。
我类似于用日期命名文件，你想说2009-01-07.log而不是1-7-2009.log，因为当你有了一堆日期之后，顺序就变得完全无用了。
一个好的命名约定应该尽量减少可以用于任何给定变量、类、方法或函数的可能名称的数量。如果只有一个可能的名字，你永远不会忘记它。
对于函数和单例类，我仔细检查函数，看看它的基本功能是否是将一种事物转换为另一种事物。我使用这个术语非常松散，但您会发现，您编写的大量函数本质上是以一种形式获得某些内容，并以另一种形式生成某些内容。
在您的例子中，听起来像是您的类将一个URL转换为一个文档。这样想有点奇怪，但完全正确，当你开始寻找这个模式时，你会发现它无处不在。
当我找到这个模式时，我总是将函数命名为x
因为您的函数将一个URL转换成一个文档，所以我会命名它
1 | DocumentFromUrl |
这种模式非常普遍。例如:
1 2 3 | atoi -> IntFromString GetWindowWidth -> WidthInPixelsFromHwnd // or DxFromWnd if you like Hungarian CreateProcess -> ProcessFromCommandLine |
如果您对订单更满意，也可以使用
选择一个惯例并坚持下去。如果在X
我学到的一个教训是，如果你找不到一个类的名称，那么这个类几乎总是有问题的：
- 你不需要它
- 它做的太多了
有时类或方法没有好的名称，这发生在我们所有人身上。然而，通常情况下，无法想出一个名字可能是暗示你的设计出了问题。你的方法有太多的责任吗？你的课是否包含了一个连贯的想法？
线程1：
1 2 3 4 5 6 7 8 9 | function programming_job(){ while (i make classes){ Give each class a name quickly; always fairly long and descriptive. Implement and test each class to see what they really are. while (not satisfied){ Re-visit each class and make small adjustments } } } |
线程2：
1 2 3 4 5 | while(true){ if (any code smells bad){ rework, rename until at least somewhat better } } |
这里没有线程。在任何地方睡眠(…)。
我确实花了很多时间，也担心在编程时任何可以命名的东西的名称。不过，我想说它很有回报。有时当我被卡住的时候，我会把它放一段时间，在休息时间，我会问周围的人是否有好的建议。
对于你的班级，我建议你使用
史蒂夫·麦康奈尔完成的书中的代码有一个很好的章节，关于变量/类/函数的命名。
我认为这是副作用。
真正的命名并不难。很难的是，命名的过程让你面对一个可怕的事实，你根本不知道自己在做什么。
事实上，我昨天刚从37号的"信号与噪音"博客上听到这句话，我当然同意：
"计算机科学中只有两个难题：缓存失效和命名。"-菲尔·卡尔顿
困难是好事。这迫使你思考这个问题，以及这个班实际上应该做什么。好的名字有助于设计好。
同意。我喜欢尽可能保持我的类型名和变量的描述性，而不要太长，但有时有些概念你找不到合适的词。
在这种情况下，向同事征求意见总是有帮助的——即使他们最终没有帮助，但至少能帮我解释清楚，让我的车轮转动。
上个月我刚刚在写命名约定：http://caseysoftware.com/blog/utility-naming-conventions
要点：
动词形容词名词结构-以结构和形容词作为可选部分
对于动词，我坚持动作动词：保存、删除、通知、更新或生成。偶尔，我会使用"process"，但只是专门指队列或工作积压。
对于名词，我使用与之交互的类或对象。在Web2Project中，这通常是任务或项目。如果是javascript与页面交互，那么它可能是body或table。关键是代码清楚地描述了与之交互的对象。
该结构是可选的，因为它是特定情况下的。列表屏幕可能请求列表或数组。web2project项目列表中使用的核心功能之一就是getprojectlist。它不修改基础数据，只修改数据的表示。
形容词完全是另一回事。它们用作名词的修饰语。像getopenprojects这样简单的东西可能很容易用getprojects和switch参数实现，但是这倾向于生成需要对对象的底层数据和/或结构有相当多了解的方法…不一定是你想鼓励的。通过拥有更显式和更具体的函数，您可以完全包装和隐藏使用它的代码的实现。这不是OO的要点之一吗？
不仅仅是命名一个类，创建一个适当的包结构可能是一个困难但有益的挑战。您需要考虑分离模块的关注点，以及它们如何与应用程序的远景相关。
现在考虑应用程序的布局：
- App
- VendorDocRequester (read from web service and provide data)
- VendorDocViewer (use requester to provide vendor docs)
我冒昧地猜测，在几节课里发生了很多事情。如果要将其重构为更具MVC化的方法，并允许小类处理单个的职责，那么最终可能会得到如下结果：
- App
- VendorDocs
- Model
- Document (plain object that holds data)
- WebServiceConsumer (deal with nitty gritty in web service)
- Controller
- DatabaseAdapter (handle persistance using ORM or other method)
- WebServiceAdapter (utilize Consumer to grab a Document and stick it in database)
- View
- HelpViewer (use DBAdapter to spit out the documention)
然后，类名依赖于名称空间来提供完整的上下文。类本身可以与应用程序内在地相关，而无需显式地这样说。因此，类名更简单，也更容易定义！
另一个非常重要的建议是：请帮自己一个忙，然后取一份head-first设计模式的副本。这是一本非常好的、容易阅读的书，它将帮助您组织应用程序并编写更好的代码。欣赏设计模式将帮助您理解您遇到的许多问题已经解决，并且您将能够将这些解决方案合并到代码中。
LeoBrodie在他的《思考》一书中写道，程序员最困难的任务就是把事情命名好，他说最重要的编程工具是同义词库。
尝试在http://thesaurus.reference.com/上使用同义词库。
除此之外，永远不要使用匈牙利符号，避免缩写，并且保持一致。
最美好的祝福.
简而言之：我同意好的名字很重要，但我认为你不必在不惜一切代价实施之前找到它们。
当然，最好从一开始就有个好名字。但是，如果您不能在2分钟内找到一个，那么稍后重命名将花费更少的时间，从生产力的角度来看，这是正确的选择。
长：一般来说，在实现一个名称之前，通常不需要考虑太久。如果实现类，则在实现时将其命名为"foo"或"dsnfdkgx"，您将看到应该为其命名的内容。
特别是在Java+Eclipse中，重命名的东西一点也不疼，因为它小心地处理所有类中的所有引用，警告您的名称冲突等等。只要类还没有在版本控制库中，我认为重命名它5次就没有什么不对。
基本上，这是一个关于重构的问题。就我个人而言，我喜欢它，尽管有时它会让我的队友感到恼火，因为他们相信永远不要碰跑步系统。从你能重构的所有东西中，改变名字是你能做的最无害的事情之一。
为什么不把helpdocumentserviceclient当作一个大嘴巴，或者helpdocumentclient……不管它是一个供应商，关键是它是处理帮助文档的Web服务的客户。
是的，命名很难。
该类只有一个合理的名称：
1 | HelpRequest |
不要让实现细节分散您的注意力。
我坚持基本原则：动词名词(论点)。示例：getDoc(docid)。
没有必要幻想。从现在起一年后，无论是你还是别人都会很容易理解。
投资一个好的重构工具！
对于我来说，我不在乎方法或类名的描述和在正确的库中有多长时间。你应该记住API的每个部分在哪里的日子已经过去很久了。
所有主要语言都有智能感知。因此，当使用第三方API时，我喜欢将其Intelise用于文档，而不是使用"实际"文档。
考虑到这一点，我可以创建一个方法名，例如
长或短的装卸工方法名称
很长——但又怎么样。现在谁不使用24英寸的屏幕！
这是制定编码标准的原因之一。有一个标准往往有助于在需要时提出姓名。它有助于解放你的思想，用于其他更有趣的事情！(-)
我建议阅读SteveMcConnell的代码完整(AmazonLink)中的相关章节，该章节包含几个规则，以帮助阅读能力甚至可维护性。
高温高压
干杯，
抢劫
不，调试对我来说是最困难的事情！-)
别忘了设计模式(不仅仅是GOF模式)是提供通用词汇表的一种很好的方式，只要适合这种情况，就应该使用它们的名称。这甚至有助于熟悉术语的新手快速理解体系结构。你正在学习的这门课应该像一个代理，甚至是一个fa？艾德？
资料员？没有上下文很难说。
它可以帮助你像一个数学家一样行事，并在你的领域中借用/发明一个词汇：用简短的简单单词来表达这个概念，而不必每次都把它拼出来。我经常看到拉丁语的长短语变成了缩略词，这使得你无论如何都需要一本字典来解释缩略词。
你用来描述问题的语言，是你应该用来描述变量、方法、对象、类等的语言。不严格地说，名词与对象匹配，动词与方法匹配。如果您缺少描述问题的单词，那么您也缺少对问题的完整理解(规范)。
如果只是在一组名称之间进行选择，那么它应该由用于构建系统的约定驱动。如果你来到了一个新的地方，被以前的惯例所揭露，那么总是值得花费一些努力来扩展它们(适当地、一致地)来覆盖这个新的案例。
如果有疑问，那就睡一觉，选择第一个最明显的名字，第二天早上——)
如果有一天你醒来发现自己错了，那么马上改变它。
保罗。
btw:document.fetch()非常明显。
我绝对能感觉到你。我感觉到你的痛苦。我想到的每一个名字在我看来都是垃圾。这一切似乎太笼统了，我想最终学会如何在我的名字中注入一点天赋和创造力，使它们真正反映出他们所描述的。
我的一个建议是查阅一个同义词库。世界有一个很好的，就像MacOSX一样。这真的可以帮助我走出迷雾，给我一个很好的起点和一些灵感。
我发现局部变量的麻烦最大。例如，我想创建一个docgetter类型的对象。所以我知道是个医生。我为什么要给它取另一个名字？我通常会给它起一个像dg(对于docgetter)或temp之类的名字，或者一些同样难以描述的名字。
我不得不承认命名是一门艺术。如果你的课程遵循某种"设计模式"(工厂等)，这会变得简单一点。
供应商文档不应该是对象吗？我的意思是，这一个是有形的，而不仅仅是你程序中某个部分的拟人化。因此，您可能有一个
不是真的。考虑到在编码中必须理解的所有困难，说命名类和方法是编程中最困难的事情之一是荒谬的。别误会我，有时很难想到好的名字，但让我们在这里真实一点。我要说的是，它是编程中最简单的部分之一。
只需在"一个词"中总结方法/类，回答它的含义？这个词不应该有等价物。
如果您是.NET开发人员，我强烈建议您阅读Brada，cwalina图书-框架设计指南。这一切都解释了。
如果这个名字能向一个外行程序员解释，那么就不需要更改它了。
我发现完成一件事后选择一个名字比较容易。重构->重命名ftw。
每个软件开发人员都应该具备写作和沟通技能的另一个原因。
我相信大量的词汇也是很重要的。
我从另一个角度看，如果你希望你的代码能被其他人阅读，这是最重要的事情之一。
尽量使它具有描述性，如果它来自第三方，为什么不在类或方法名称中包含[第三方的名称]。
如果要花很长时间，只需使用任何名称，后面的单词你可以更改它。
我感觉到你的痛苦。：
我希望有一个工具可以与数据字典(一个描述各种变量/方法名称的文件，我猜有点像javadoc)一起检查源代码，这样您就可以编写这样的代码：
1 2 3 4 5 6 7 8 9 10 | class Battery { double I; // current double T; // temperature double V; // voltage double Q; // charge void update(double Inew, double dt) { I = Inew; Q += I*dt; } // ... etc ... }; |
代码审查工具可以做很多不同的事情，以便更容易地在上下文中查看代码，包括显示i=current的提醒(例如，在窗口右侧的窗格中，它将显示您单击的代码中位置的变量定义/语义/注释)，甚至允许您执行"虚拟引用"ctoring"作为代码审阅者，您可以根据可读性/显示原因将某些内容重命名为您喜欢的内容，而不必实际更改存储在磁盘上的代码。
尽管我喜欢自述的名字，但我讨厌读像
我是一个EE/系统工程师，首先承担的软件责任很小，最后我真的不在乎变量的名称，只要我有一个方便的方法来说明它是什么，并将它映射到我自己的被控制系统的内部模型中。
我通常觉得很自然。我总是使用非常短的方法，从来不会超过6行的smalltalk代码(自动格式化)，所以我真的不难说出这个方法是关于什么的。
有时类名是困难的，因为我要选择的词在系统中的某个地方使用，因为有时同一个词在不同的上下文中有不同的含义。我希望在这些情况下，允许使用一些类似维基百科的语法，这样我就可以将我的类命名为"task(to do list item)"。在这是合法的之前，我用它做了一个很大的德语单词：todolistitemtask。您可能已经猜到了：我的方法名也可能很长。但我认为它们是可读的。
所以，在您的例子中，您的类是一个"getter"，或retriever，或其他什么。您确定这应该在类中建模吗？难道供应商文档不能自己请求吗？类似于vendoroc.requestfrom(source)；更容易命名，不是吗？
干杯，
尼科
如果10个人中有8个人理解它，那么您可以安全地假设它是可理解的、可读的和清晰的。总有一两个挑剔的人会无缘无故地尝试和指责你，除了他们是小气的。
我要做的是，如果我记不住的话，检查它是否会变长。
当每一个合理的名字看起来太长或模棱两可时，你可以尝试使用一些不那么合理的名字，例如：
- GoforHelpLassie类
- DunnoaskTechSupport类
- RTFVM类[其中V代表供应商]
确保该名称确实是唯一的，并且在类的顶部有一个描述性的注释，因为在代码中看到它的任何人都需要查找它来找出它的作用(但是当他们这样做时，他们可能会发现它更容易记住)。
我觉得不难。如果你不能说出它的名字，那么也许你不需要它。你的设计越好，就越容易说出你的设计所做的事情。
现在温度变量，情况不同了。：)