每个模块组件重复模块名称 [英] Repeating module name for each module component
问题描述
有关角应用结构博客文章概述了新的建议angularjs项目著名的最佳实践建议结构现在是面向构件，并不功能为导向，或在初始发行GitHub的命名 - 通过功能组织。
The famous Best Practice Recommendations for Angular App Structure blog post outlines the new recommended angularjs project structure which is now component-oriented, not functionally-oriented, or as named in the initial github issue - "Organized by Feature".
的博文认为，每个模块内的每个文件应该以模块名，例如启动：
The blogpost suggests that each file inside each module should start with the module name, e.g.:
userlogin/
userlogin.js
userlogin.css
userlogin.html
userlogin-directive.js
userlogin-directive_test.js
userlogin-service.js
userlogin-service_test.js
现在的问题是：什么是点，优点和重复模块中每个文件名里的模块名称的利弊，而不是其功能命名的文件？例如：
The question is: what is the point, pros and cons of repeating the module name inside each filename in the module as opposed to having the files named functionally? For example:
userlogin/
userlogin.js
userlogin.css
userlogin.html
controllers.js
directives.js
services.js
我想问的原因是，我从 Django的 未来世界上哪里有有项目和应用的有点类似的想法。每个应用程序通常都有自己的 models.py ， views.py ， urls.py ， tests.py 。有没有重复的应用程序名称的脚本名称中。
The reason I ask is that I'm coming from a Django world where there is a somewhat similar idea of having projects and apps. Each app usually has it's own models.py, views.py, urls.py, tests.py. There is no repeating app name inside the script names.
我希望我不是一个路口意见为主线，还有为后续的做法正当的理由。
I hope I'm not crossing an opinion-based line and there is a legitimate reason for following the approach.
推荐答案
有一个很好的理由，这是提高一个非常重要的方面任何不平凡的codeBase的（尤其是当开发大型团队都参与），也就是我们所说的overviewability。
There is a very good reason and it is for improving a very important aspect for any non-trivial codebase (especially when large teams of developers are involved), namely what we call "overviewability".
Overviewability是codeBase类的organzation（文件夹结构，文件命名，元对象等）来提供实现的软件的快速和内容概述的能力。
"Overviewability" is the ability of the codebase's organzation (folder structure, file naming, meta-objects etc) to provide a quick and informative overview of the implemented software.
的overviewability的意义与codeBase的大小呈指数增加并且开发团队的项目*工作的原因如下（非穷尽列表）的
The "overviewability's" significance increases exponentially with the size of the codebase and that of the developers team working on the project* for the following reasons (non-exhaustive list):
-
当一个codeBase的是大的，也可以原封不动的code的某些部分的概率为特定时间段的增加（如增加了这种冷时段的持续时间）。
When a codebase is large, the probability of certain parts of the code to be left untouched for a specific time period increases (as increases the duration of this "cold" period).
在新成员加入我们的团队，你希望他们长大要尽快的速度（而不是让他们在这个过程中受挫）。 Overviewability有助于提供整个项目的一个很好的高层次的抽象，通常还给出了如何工作（更多的往往不是它创造熟悉的感觉感好，就好像你看过codeBase类之前 - 虽然你没有）
When new members join the team, you want them to be brought up to speed as soon as possible (and not get them frustrated in the process). "Overviewability" helps provide a good high-level abstraction of the whole project and usually also gives a good sense of how things work (more often than not it creates a feeling of familiarity; it's as if you've seen the codebase before - although you haven't).
的那么，好吧，overviewability是非常重要的。这就是为什么我们有这个漂亮，组件为中心的结构等，但为什么 prefixing与组件的名称每个文件？ 的
"So, OK, "overviewability" is important. That's why we have this nice, component-centric structure etc. But why prefixing each file with the component's name ?"
那么，它听起来好笑，但prefixing所有组件相关的文件名可以确保一个特定的顺序。例如。在HTML部分或CSS总会出现的控制器之前等：
Well, it might sound funny, but prefixing all component-related filenames ensures a specific order. E.g. the HTML partial or the CSS will always appear before the controllers etc:
...
userlogin.html
userlogin-controller.js
...
凡不是为preFIX，你会最终取决于组件的名字各种命令。例如：
Where it not for the prefix, you would end up with various orders depending on the name of the component. E.g.:
... ... ...
controller.js controller.js bookself.html
... ... ...
service.js VS service.js VS controller.js
... ... ...
userlogin.html zombi.html service.js
... ... ...
使用preFIX确保文件出现在特定的顺序：控制器中的HTML部分，服务还等例如来后总是：
Using a prefix ensures the files appear in specific order: controller comes always after the HTML partial, service also etc. E.g.:
... ... ...
userlogin.html zombi.html bookself.html
... ... ...
userlogin-controller.js VS zombi-controller.js VS bookself-controller.js
... ... ...
userlogin-service.js zombi-service.js bookself-service.js
... ... ...
这似乎微不足道，但它不是;尤其是作为一个得到习惯了。结果
需要注意的是人的心灵在识别的视觉模式（如由树的节点重新$ P $的文件以及文件夹结构的文件资源管理器psentation中创建的）。
This might seem trivial, but it's not; especially as one gets used to it.
Note that the human mind is very good at recognizing visual patterns (like the ones created by a tree-node representation of the folder- and file-structure in a file-explorer).
即。控制器不驻留在的一档名为＆LT;成分＆gt; -controllers.js的结果。
它位于的第一个文件名为显著长于previous文件的。结果
该服务（如果有的话）驻留在的末具有较小名称的文件的等。
I.e. the controllers do not reside in a file named "<component>-controllers.js".
It resides in the first file whose name is significantly longer than the previous files.
The service (if any) resides in the file with the smaller name at the end, etc.
混乱，向上（即乱顺序，因为起始字母或混乱的相对长度，因为长/短组件名称），你有自己类似不必读取硬盘驱动器的东西的情况，而不是刚刚从RAM读出它。 （没有开发商愿意去那里：））
Mess that up (i.e. mess the order up because of the starting letter or mess their relative lengths up because of long/short component names) and you have yourself a situation similar to having to read something from the hard-drive, instead of just reading it from the RAM. (No developer wants to go there :))
<子>
*：其实，这就是我们所说的开发团队通量这在这里很重要，即团队成员将如何经常请假（如对别的工作，离开公司等）或将出台的新成员
通常，该球队越大，磁通越大。
这篇关于每个模块组件重复模块名称的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
