这是一个包含 2000 行代码的庞然大物。 在其中浏览或轻松查找所需内容很困难。 可以做什么? 本文并非关于实际拆分文件(尽管那也是一个好文章),主要是在您需要保持文件原样时应该采取的措施。
不要创建如此大的文件
理想情况下,您不会让文件变得太长。 文件越长,它就越有可能成为一个垃圾场,而不是机器中一个合适的齿轮。
这里我们指的是编写的文件。 您的生产 `style.css` 文件可能确实很长,但它可能是由较小的部分编译而成的,并组织成有意义的部分。
如果您的编写文件已经太长,您能否找到一种有意义的方法将其拆分? 如果可以,这可能是个好主意。 也许您的庞大 `user_controller.rb` 可以拆分成多个关注点,主控制器可以继承这些关注点。
抽象在起作用!
但假设由于某种原因,在您的项目中拥有一个超长文件是有意义的。 它需要以这种方式存在,并且您需要一种方法使其更易于管理。 也许我们可以稍微玩弄一下。
ASCII 艺术块
如果您在文件中进行了大量上下滚动,那么在各部分之间放置大量空格可能会有所帮助。 然后,如何使用一个大型的带注释的 ASCII 艺术文本 块来标记该部分?
______
| ____|
| |__ ___ _ __ _ __ ___ ___
| __/ _ \| '__| '_ ` _ \/ __|
| | | (_) | | | | | | | \__ \
|_| \___/|_| |_| |_| |_|___/
如果您使用带有“迷你地图”的编辑器,这些内容确实会脱颖而出,正如 Xah Lee 指出的那样。

注释块
也许只是空格和大型注释代码块脱颖而出,因此,与其追求花哨的艺术效果,不如变得实用一些,并使用元数据标记每个部分。
/*
Section: Form Styles
Purpose: To style form elements like <input>s and <button>s and such.
Author: Chris Coyier
Last updated: September 28, 2015
Favorite TV Show: Northern Exposure
*/
奇怪的缩进
代码倾向于聚集在左侧。 当事物缩进很远而没有导致它的嵌套时,它看起来很奇怪。 也许您可以利用它来发挥自己的优势。
.main-header {
background: black;
color: white;
}
// *****************
// -----------------
// FOOTER STYLES
// _________________
// *****************
.main-footer {
background: white;
color: black;
}
长行
尤其是在您没有打开换行/软换行的情况下,超长行可以很好地分割内容。
// XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
您可以搜索的内容
如果您使用了命名部分的约定,那么在项目(或项目的部分或单个文件)中进行搜索将产生良好的结果,以查找这些部分。

搜索比滚动快得多!
使用代码折叠功能
如果您的编辑器具有代码折叠功能,请使用它! 它的全部意义在于暂时隐藏代码块,使其不会分散注意力。

源代码映射
如果您使用的是编译成浏览器使用的其他内容的语言(例如 Sass、CoffeeScript、Closure 编译器等),它可能会提供源代码映射,这意味着 DevTools 可以告诉您代码片段在原始编写文件中的哪一行,而不仅仅是编译版本。 这样您就知道需要转到哪个文件进行编辑。

并且您也了解哪一行,因此无论它在哪里,您都可以直接跳转到它。
您的编辑器是否以特殊方式为您提供帮助?
您的编辑器在“在项目中查找”功能方面是否非常出色,可以将您直接跳转到该行? 使用它!
您的编辑器是否有其他酷炫的方法在文件中四处跳转? 我知道“转到符号”在 Sublime Text 中非常受欢迎,并且 Jetbrains 也有此功能(我相信许多其他编辑器也有)。
您的编辑器(或插件)是否有某种方法可以通过代码部分进行制表? 试试看!
ASCII 艺术块非常有用,尤其是在 Sublime Text 的迷你地图中
我仍然使用 Coda,因此我倾向于依赖它们的 ! 注释横幅,以便该部分标题在代码导航器中作为其自身项目显示,位于函数、方法、类定义、include/require 调用等之间。
或者根本不要创建大型文件,这出于各种原因是可取的。 使用 Sass/PostCSS/任何内容用于 CSS;使用 browserify 用于 Javascript;使用任何 SSI 用于 HTML。 拥有 2000 行的文件只是管理不善,注释块并不能解决任何问题。
在发表评论之前我没有阅读文章,真不应该。 :(
酷炫 - 这些迷你地图第一次对我来说似乎有意义(有点)。
但是,字体必须是某种“填充”变体 - 屏幕截图中的字体似乎是“Banner3”(来自链接的生成器)。
当然,如前所述,控制这些文件的大小是首选。 然后 - 为每个部分添加 7 个字符高的注释并不能完全帮助减少垂直文件大小 ;) 因此我当然更喜欢良好的结构和搜索。 但对于不值得清理的继承混乱 - 也许可以。 因此感谢您的提示!
顺便说一句,Atom 也有一个名为“minimap”的包。
但是,真的,不要编写如此大的文件!
您很有可能正在打包非常不同的功能代码,因此将它们分离到不同的文件中是很自然的。
无论如何,迷你地图的技巧很不错。
我使用 Sublime Text 3,打开/关闭注释,例如
会为内部的所有文本添加亮粉色的实心背景颜色(您不会错过它)。 令人尴尬的是,我不记得曾在 Sublime 设置中设置过任何类似的东西,但我认为这与主题“Monokai”有关。
https://packagecontrol.io/packages/Theme%20-%20Monokai
哦,天哪! 我也不记得曾经添加该图像作为我的 Gravatar! 对不起!
我使用带有 Web Essentials 的 Visual Studio,它可以折叠代码树,但我仍然会选择将其拆分成多个文件
忘记提了,这是针对Lesscss的
Visual Studio 配合 Web Essentials,对于 CSS 我使用注释区域,然后 ctrl M+L 折叠所有内容!
如果你使用 Github 的 Atom 编辑器,有一个插件可以非常出色地完成 ASCII 横幅:https://atom.io/packages/figlet
在代码中输入一个单词,按下键盘组合键。搞定!
结合切换注释功能(Mac 上为 Shift+Cmd+3),你不需要比输入文本多花太多时间。
你甚至可以从不同的 ASCII 艺术字体样式中选择。
……哦,Sublime Text(2 & 3)也有非常类似的东西。
https://github.com/adamchainz/SublimeFiglet
对于 Sublime Text,有 Table of Comments 插件,它可以为以特定标记开头的注释创建导航(默认情况下为
>
)。在我们团队中,对于 Sass/Less,我们标准化使用
#
(就像 Markdown 标题一样),并且我们使用一些格式使其在浏览代码时更明显。但装饰并不那么重要,你可以使用 *文档样式注释 (
/** # Hello there */
) 来代替。现在我使用 Atom,所以我错过了这个功能。我尝试依靠将代码分解成独立的文件,我们确实这样做了,但某些组件仍然有 200 行甚至 500 行样式,因此一些结构仍然有助于导航,当然还有维护它们。
除了编写摘要之外,我通常还喜欢在我的 CSS 中放置一个快速 DOM 概述。这通常可以节省时间。
哇!
这种“注释块”样式对于非常大的样式和更大的团队来说似乎非常实用。