css3动画源代码库_清理CSS代码库

悠悠 2022-12-03 09:59 171阅读 0赞

css3动画源代码库

You have just been onboarded to an existing project to replace a departing developer. Or maybe you just opened that old project of yours from a few years ago. You are faced with dread and horror when looking at the code. You can do only one thing: Clean up this mess! Does that sound familiar to you? Of course it does, we all encounter this at some point or the other.

您刚刚加入现有项目以替换即将离任的开发人员。 或者，也许您是几年前刚刚打开的那个旧项目。 在查看代码时，您将面临恐惧和恐惧。 您只能做一件事：清理混乱！ 这听起来对您熟悉吗？ 当然可以，在某些时候我们都会遇到这种情况。

You know that cleaning up a CSS codebase is going to be a tremendous task. There are so many things to do, yet so little time – especially when the client/boss/colleague advocates the good ol’ “don’t fix what’s not broken” adage. You don’t really know where to start!

您知道清理CSS代码库将是一项艰巨的任务。 有很多事情要做，却只有很少的时间-特别是当客户/老板/同事提倡“不要解决未破的事情”的格言时。 您真的不知道从哪里开始！

Well you’re in luck because I’ve done my share of CSS clean-ups and I’m here to give you some hints to get started with this. It’s all about grabbing the low hanging fruit.

好吧，您很幸运，因为我已经完成了CSS清理工作，并且在这里为您提供一些入门的提示。 这一切都是为了抓住低垂的果实。

## 摆脱困境 **(**Lint the Hell Out of It**)** ##

In this section, I will assume your codebase uses [Sass][]. Not only because it’s a reasonable assumption nowadays, but also because I’ve noticed poor usage of Sass is often partially responsible for a messy codebase. Still, this article might be relevant to you even if you don’t use a preprocessor, so bear with me please.

在本节中，我将假设您的代码库使用[Sass][] 。 不仅是因为现在这是一个合理的假设，而且还因为我注意到Sass的使用不当常常导致凌乱的代码库。 尽管如此，即使您不使用预处理程序，本文也可能与您相关，请多多包涵。

The first thing I like to do when I need to take over a codebase is lint it. Linting is the process of running a program that looks for potential errors and bad practices. I believe making the code clean is the first step towards making the code good. [Here is an insightful Stack Overflow thread][] about the etymology of the word “lint”.

当我需要接管一个代码库时，我想做的第一件事就是将它整理好。 整理是运行程序的过程，该程序查找潜在的错误和不良做法。 我相信使代码整洁是使代码良好的第一步。 [这是][Here is an insightful Stack Overflow thread]关于“棉绒”一词的词源[的有见地的Stack Overflow主题][Here is an insightful Stack Overflow thread] 。

Sass has a Ruby-based linter called [SCSS-Lint][]. You can configure it yourself or grab the recommended configuration file [from Sass-Guidelines][] to get started right away. There is also a Node.js version called [Sass-lint][], although they are not 100% inter-operable, so your mileage may vary.

Sass有一个称为[SCSS-Lint][]的基于Ruby [的林特][SCSS-Lint] 。 您可以自己配置它，也可以[从Sass-Guidelines][from Sass-Guidelines]中获取推荐的配置文件以立即开始使用。 还有一个名为[Sass-lint][]的Node.js版本，尽管它们不是100％可互操作的，所以您的工作量可能会有所不同。

Try running SCSS-Lint on your Sass folder to check for errors. Chances are high that you’ll get overwhelmed with a wall of errors. This is usually the time where you’ll be tempted to give up. But bear with me! At this point, you can either try to make your linting file a bit less strict in regard to rules you don’t really care about (like color format) or you can tackle the beast up front and lint the hell out of it!

尝试在Sass文件夹上运行SCSS-Lint来检查错误。 出现错误的可能性很高，很可能使您不知所措。 通常这是您倾向于放弃的时间。 但是，请忍受我！ 在这一点上，您可以尝试对您不太喜欢的规则(例如颜色格式)使整理文件的严格性降低一些，或者可以预先解决野兽并将其掉毛的麻烦！

## 修复发现的棉绒错误 **(**Fixing Linting Errors Found**)** ##

It’s time to fix what needs to be fixed. There are two ways of doing this. The first is to go through files one by one and update what seems wrong and/or odd, such as bad naming conventions, overly-deep-nested selectors, poorly formatted code, etc. The second (and my favourite) one is to start with a bit of search and replace. I don’t know about you but I love regular expressions, so it’s always quite fun when I have to do this.

现在该修复需要修复的内容了。 有两种方法可以做到这一点。 第一种是逐个检查文件并更新看起来错误和/或奇怪的内容，例如不良的命名约定，嵌套深度过深的选择器，格式欠佳的代码等。第二种(也是我的最爱)是开始进行一些搜索和替换。 我不了解您，但是我喜欢正则表达式，所以当我必须这样做时，它总是很有趣。

For instance, let’s say you want to add the missing leading zero in front of all the floating-point numbers (i.e. a numeric value between 0 and 1) — the [LeadingZero][] rule from SCSS-lint. You can search for `\s+\.(\d+)` (all numbers following a space and a dot) and replace it with `\ 0.$1` (a space, a zero, a dot, and the found number). Or if you want to honor the [BorderZero][] rule for SCSS-lint, you can replace `border: none` with `border: 0` in your IDE. Simple as pie!

例如，假设您要在所有浮点数(即介于0到1之间的数值)前面添加缺失的前导零(SCSS-lint中的[LeadingZero][]规则)。 您可以搜索`\s+\.(\d+)` (空格和点后面的所有数字)，然后将其替换为`\ 0.$1` (空格，零，点和找到的数字)。 或者，如果您想遵守SCSS-lint的[BorderZero][]规则，则可以在IDE中将`border: none`替换为`border: 0` 。 简单如馅饼！

I recently started the [scss-lint-regex][] repository on GitHub to gather these regular expressions in one place. Be sure to have a look if you are struggling with linting a large project. Also beware with search and replace as it sometimes has unexpected side effects. After each replacement, be sure to perform a `git diff` to check what has been updated so you can make sure that you did not introduce a bug.

我最近在GitHub上启动了[scss-lint-regex][]存储库，以将这些正则表达式集中在一个地方。 如果您正在努力完成一个大型项目，请务必看看。 也要提防搜索和替换，因为它有时会产生意想不到的副作用。 每次替换后，请确保执行`git diff`来检查已更新的内容，以确保没有引入错误。

Once you’re done with transversal editing, you won’t escape the manual file crawling to clean everything that needs to be cleaned (poor indentation, missing or extra empty lines, missing spaces, etc.). It takes a lot of time, but it will help a lot for the next step, so it’s important to start with that.

一旦完成了横向编辑，便无法逃脱手动文件爬网来清理所有需要清理的内容(缩进不良，缺少或多余的空行，缺少空格等)。 这会花费很多时间，但对下一步会有所帮助，因此从此开始很重要。

## 修改结构 **(**Revise the Structure**)** ##

What I often find disturbing when I get onboarded to an existing project is the absence of proper project architecture. There probably was one at the very beginning, but things usually get out of hand and this brief idea of methodology got lost somewhere along the line. Still, this is incredibly important.

当我加入现有项目时，经常会感到困扰的是缺少适当的项目架构。 可能一开始就是这样，但是事情通常会变得一发不可收拾，这种简单的方法论思想迷失了方向。 尽管如此，这仍然非常重要。

It does not really matter which methodology you choose as long as you feel comfortable with it and stick to it. It could be [SMACSS][], it could be [7-1][], it could [ITCSS][] – take your pick! Then try to restructure things to make the code compliant to the chosen methodology. I mostly use the 7-1 pattern introduced in Sass Guidelines, so I’ll give you a few tips to improve things if you decide to go this way.

只要您选择合适的方法并坚持下去，就没有关系。 可以是[SMACSS][] ，也可以是[7-1][] ，也可以是[ITCSS][] －随您便！ 然后尝试重组事物以使代码符合所选方法。 我主要使用Sass Guidelines中介绍的7-1模式，因此，如果您决定采用这种方式，我将为您提供一些改进方面的技巧。

Start with the [*vendor* folder][vendor_ folder] as it’s the one asking no questions. Move any non-packaged third-party library into there (that is, any library not treated as a regular dependency through [npm][] or [Bundler][]).

从[*vendor*文件夹][vendor_ folder]开始，因为它是不问任何问题的[文件夹][vendor_ folder] 。 将所有未打包的第三方库移动到那里(即，任何未通过[npm][]或[Bundler][]视为常规依赖项的库)。

Then, move on to the [*abstracts* folder][abstracts_ folder]. Make sure all the variables, mixins, functions and placeholders of the project are defined in there. Feel free to organize it the way you want here as long as you don’t end up with variables and mixins in all the files of the codebase. I also tend to look for unnecessary variables (and mixins) at that time. Indeed I often find countless variables that are used once or twice only (in other words not worth it).

然后，移至[*abstracts*文件夹][abstracts_ folder] 。 确保在其中定义了项目的所有变量，混合，函数和占位符。 只要您在代码库的所有文件中都没有变量和mixins结尾，就可以按自己的方式随意组织它。 那时我也倾向于寻找不必要的变量(和混合)。 确实，我经常发现无数的变量仅使用了一次或两次(换句话说，不值得)。

Once you’re done with that, it’s your call. You can either try to make sure that everything in the [*base* folder][base_ folder] actually is base stuff and not component related, or you could have a look at the [*layout* folder][layout_ folder] to check if everything regarding the overall layout lives in there and is correctly documented.

完成此操作后，就可以接听电话了。 您可以尝试确保[*基本*文件夹][base_ folder]中的所有内容实际上都是基本内容，而不与组件相关，或者可以查看[*布局*文件夹][layout_ folder]以检查有关总体布局的所有内容是否都存在于其中并正确记录。

Finally, you will have to tackle the [*components*][components] which is likely to be a colossal task. My advice here would be to try to make components as small and re-usable as possible. It doesn’t matter if you double the number, as long as you can make them context agnostic and easy to read, understand, and update.

最后，您将不得不解决可能是一项艰巨任务的[*组件*][components] 。 我的建议是尝试使组件尽可能小和可重用。 只要将数字加倍即可，只要您可以使它们与上下文无关，并且易于阅读，理解和更新即可。

For instance, it is not a bad thing to have a component as small as this:

例如，拥有这样小的组件并不是一件坏事：

.quote {
      padding: 10px;
    }
    
    .quote__attribution {
      font-size: 80%;
    }
    
    .quote > :first-child {
      margin-top: 0;
    }
    
    .quote > :last-child {
      margin-bottom: 0;
    }

Think modular. Small. Simple. Independant.

考虑模块化。 小。 简单。 独立的

## 去除多余的 **(**Remove the Excess**)** ##

I believe the biggest difference between good and bad CSS is the amount of code needed to Make It Work™. CSS as a language is pretty easy to grasp. Anybody could make pretty much every layout with a bit of trial and error. However being able to build something with the bare minimum of CSS required to make it work, and to keep it that way, is a real challenge.

我相信好CSS和不好CSS之间的最大区别在于，使CSS正常工作所需的代码量。 CSS作为一种语言非常容易掌握。 任何人都可以通过反复试验来制作几乎所有布局。 但是，能够用使之工作并保持这种状态所需的最低限度CSS来构建某些东西，确实是一个挑战。

It’s been over 3 years but [this tweet from Nicolas Gallagher][] remains my favourite quote about CSS:

已经过去三年了，但是[Nicolas Gallagher的这条推文][this tweet from Nicolas Gallagher]仍然是我最喜欢CSS报价：

> Within "bad" CSS, it's very hard to write "good" CSS. Within "good" CSS, it's very easy to bolt on "bad" CSS and initiate code rot.
> 
> 在“不良” CSS中，很难编写“良好” CSS。 在“好” CSS中，很容易使用“坏” CSS并启动代码腐烂。
> 
> — Nicolas (@necolas) [September 26, 2012][this tweet from Nicolas Gallagher]
> 
> — Nicolas(@necolas) [2012年9月26日][this tweet from Nicolas Gallagher]

Obsolescence is the real plague of CSS. When building something with CSS, we often go back and forth and try a few things – to the point where we usually end up with a few unneeded declarations. For instance an `overflow: hidden` that became unnecessary, or a `font-size` that makes no difference. By leaving them, we pile up technical debt. That’s Bad™.

淘汰是CSS的真正困扰。 在使用CSS进行构建时，我们经常来回尝试一些事情-到最后通常会出现一些不需要的声明。 例如， `overflow: hidden`不必要的`overflow: hidden` ，或没有区别的`font-size` 。 离开他们，我们积累了技术债务。 那是Bad™。

When *writing* CSS, what I like to do right before committing a piece of CSS work is opening the Developer Tools, and toggling each CSS declaration I’ve written to see if they each have an impact. If they don’t, I ask myself why they are there in the first place. If they turn out to be unnecessary, I remove them. By doing something as simple as this, I make sure only useful junk-free code gets pushed to the repository.

*编写* CSS时，在完成CSS工作之前，我想做的就是打开开发人员工具，并切换我编写的每个CSS声明，看看它们是否有影响。 如果没有，我问自己为什么首先要在那里。 如果事实证明它们不必要，我将其删除。 通过这样简单的操作，我确保仅将有用的无垃圾代码推送到存储库中。

*Cleaning up* a CSS codebase is no different. Locate a component you would like to clean up, open the DevTools, and try finding useless declarations. Sometimes in order to remove some CSS, we need to move some styles upper in the tree to benefit from the cascade. Consider the following example reduced to its bare minimum:

*清理* CSS代码库没有什么不同。 找到您要清理的组件，打开DevTools，然后尝试查找无用的声明。 有时为了删除一些CSS，我们需要在树中上移一些样式以从层叠中受益。 考虑下面的示例，它降至最低限度：

.parent {
      /* ...stuff here... */
    }
    
    .child-A {
      color: red;
    }
    
    .child-B {
      color: red;
    }

A clean way to optimise this would be to move the `color: red` declaration to the parent and let the cascade do the rest. Of course, real life examples are usually more complex, but that shows how we sometimes forget to take advantage of the *C* in \*C\*SS.

一种优化此方法的干净方法是将`color: red`声明移至父级，然后由级联执行其余操作。 当然，现实生活中的例子通常较为复杂，但显示了我们如何有时会忘记采取\* C \* SS的*C*的优势。

## CSS很聪明，您也应该 **(**CSS is Clever, You Should Be Too**)** ##

A thing I come across often is the lack of understanding of the `inherit`, `initial`, and `currentcolor` values. Say you want your links to be the same color as the core text (because the underline is enough). The following is a *bad* way of doing:

我经常碰到的事情是缺乏理解`inherit` ， `initial`和`currentcolor`值。 假设您希望链接的颜色与核心文本的颜色相同(因为带下划线就足够了)。 以下是一个*不好的*方法：

a {
      color: black; /* Nope */
    }

The reason why it is a poor solution should be obvious: if you change the color of the body copy, the link color will be de-synchronized. If you are thinking of using a variable, you are making things unnecessarily complex. On top of that, if a link ends up in a grey paragraph (inside a blockquote for instance), it won’t match the color!

解决方案不佳的原因很明显：如果更改正文副本的颜色，则链接颜色将不同步。 如果您正在考虑使用变量，则会使事情变得不必要地复杂。 最重要的是，如果链接以灰色段结尾(例如，在blockquote内)，则该颜色将不匹配！

CSS has a built-in way of handling this, with the `inherit` value.

CSS具有使用`inherit`值来处理此问题的内置方法。

a {
      color: inherit; /* Yay! */
    }

It’s as simple as that. Thanks to this, links will always inherit the color of their parent. Which might also be inheriting the color of its ancestors, and so on.

就这么简单。 因此，链接将始终继承其父级的颜色。 可能还继承了其祖先的颜色，依此类推。

Along the same lines, when reinitialising a property to its default value, it is a poor idea to hard-code said value. CSS has the `initial` magic value precisely for such a scenario. While it usually doesn’t make a difference, there are cases where it really matters, like with direction-based properties such as `text-align`. When resetting `text-align`, setting `left` could be damaging for RTL languages; `initial` would be the way to go (or even better, `start`, but this value doesn’t have support in IE9).

同样，在将属性重新初始化为其默认值时，硬编码该值是一个糟糕的主意。 CSS在这种情况下具有`initial`魔力值。 尽管通常没有什么区别，但在某些情况下它确实很重要，例如基于方向的属性(例如`text-align` 。 重置`text-align` ， `left`设置可能会损坏RTL语言； `initial`的方式是开始(或者甚至更好，是`start` ，但是IE9中没有此值)。

Last but not least, the number of CSS developers not knowing `currentcolor` is too damn high. If you don’t know about it, don’t feel bad, but ask yourself this: how is it that when not specifying a border color, it automagically matches the color of the element? Well, this happens because the default value for `border-color` is `currentcolor` ([check the spec][]). Quite an obvious name, you will concede.

最后但并非最不重要的`currentcolor`是，不知道`currentcolor`CSS开发人员数量太多了。 如果您不了解它，就不会感到难过，但是请问自己：未指定边框颜色时，它如何自动匹配元素的颜色？ 好吧，这是因为`border-color`的默认值为`currentcolor` ( [请检查spec][check the spec] )。 您将承认一个很明显的名字。

My point is, if you want something to share the color with the font of an element, use `currentcolor` rather than a hard-coded value or a Sass variable.

我的观点是，如果您希望某些内容与元素的字体共享颜色，请使用`currentcolor`而不是硬编码值或Sass变量。

.element {
      color: deeppink;
      border: 1px solid; /* Color is implicit with `currentcolor` */
    }
    
    .element svg {
      fill: currentcolor; /* Fill color will be same as text */
    }

All these things are basic CSS features. They are what makes CSS what it is. Still, they are incredibly under-used. So if you have to improve the code of a component, these are the kinds of improvements you’ll want to make.

所有这些都是CSS的基本功能。 它们就是使CSS成为现实的原因。 但是，它们的使用率仍然令人难以置信。 因此，如果您必须改进组件的代码，则需要进行这些改进。

## 让你的Git好 **(**Get Your Git Good**)** ##

Refactoring a CSS codebase is *a lot* of work. You are likely to update dozens and dozens of file. You are also likely to break things along the way. Let’s be honest, we all make mistakes, and when dealing with such huge changes, it would be very impressive if you succeeded in cleaning everything without even a tiny misstep.

重构CSS代码库*需要大量*工作。 您可能会更新数十个文件。 您也可能会破坏整个过程。 坦白地说，我们都会犯错，当处理如此巨大的变化时，如果您成功清理所有内容而没有一点失误，那将是非常令人印象深刻的。

Because of this, I highly recommend you get very assiduous with your version control (I think it’s fair to assume [Git][] here). That means commits doing one thing and one thing only so that it’s possible to come back to a step containing a bug without struggling like hell with conflicts.

因此，我强烈建议您对版本控制非常执着(我认为在这里假设使用[Git][]是公平的)。 这意味着只做一件事和做一件事，这样就可以返回到包含错误的步骤，而不会像地狱般陷入冲突。

I know for many people Git is hard and obscure, and digging into how to make it simple is way outside of the scope of this article. You have to trust me on this though: make your Git history a poem if you don’t want to get mad.

我知道对于许多人来说，Git很难而且晦涩难懂，而深入研究如何使其变得简单不在本文的讨论范围之内。 但是，您必须在这方面相信我：如果您不想生气，请把您的Git历史作为一首诗。

## 结语 **(**Wrapping it Up**)** ##

Let’s sum up and have a little tl;dr for the lazy readers:

让我们总结一下，为那些懒惰的读者写一些tl; dr：

Cleaning a CSS/Sass project is difficult because it is hard to evaluate the impact of the update or removal of a line of CSS. This is mostly because CSS is hardly testable. Because of this, you have to be careful.

清理CSS / Sass项目很困难，因为很难评估更新或删除一行CSS的影响。 这主要是因为CSS几乎不可测试。 因此，您必须小心。

Start with linting your code so it gets pretty. Start with this to make your life easier later on. This is also a good way to gain a valuable overview of the state of the codebase without risking much (fixing syntactic dirt is unlikely to cause any trouble).

从整理代码开始，代码变得漂亮。 从此开始，使您以后的生活更轻松。 这也是获得宝贵的代码库状态概览而又不冒太大风险的好方法(修复语法污垢不太可能引起任何麻烦)。

Next, make sure your project embraces a structure methodology. It doesn’t matter which one, as long as it’s done properly. If your project is not really orchestrated into components, this would be a good opportunity to start on this path. Find reusable chunks of interface, and extract their styles into their own partials. Feel free to document them a bit so it becomes easier and you get a feel of progression.

接下来，确保您的项目采用结构化方法。 只要正确完成，哪一个都没关系。 如果您的项目没有真正编排成组件，那么这将是一个走这条路的好机会。 查找可重用的接口块，并将其样式提取到自己的部分中。 随时对其进行记录，这样会变得更加容易，并且您会有所进步。

Once you have cleaned up the project and put everything in the right place, it’s time to improve the CSS itself. Check if you can remove things first; we often write way too much code. Then try to optimise the code so it’s less repetitive. Beware not to over-engineer though! You’re supposed to remove complexity, not add it. Also feel free to comment everything you do that might not seem obvious at the first glance.

清理完项目并将所有内容放置在正确的位置后，就该改进CSS本身了。 请检查是否可以先移除东西； 我们经常编写太多代码。 然后尝试优化代码，以减少重复性。 但是要注意不要过度设计！ 您应该删除复杂性，而不是添加复杂性。 乍看之下，也可以随意评论您所做的一切似乎并不明显的事情。

Finally, commit your work regularly and logically. Bundle your changes in small commits doing a single thing each so it’s simple to go back in history if something goes wrong.

最后，定期且逻辑地提交您的工作。 将您的更改捆绑在每次只做一件事的小提交中，因此如果出了问题，可以很容易地回顾历史。

Last, but not least, don’t forget to celebrate when you’re done. Good luck!

最后但并非最不重要的一点是，完成后别忘了庆祝。 祝好运！

> 翻译自: [https://www.sitepoint.com/cleaning-up-a-css-codebase/][https_www.sitepoint.com_cleaning-up-a-css-codebase]

css3动画源代码库

[Sass]: http://sass-lang.com
[Here is an insightful Stack Overflow thread]: http://stackoverflow.com/questions/8503559/what-is-linting
[SCSS-Lint]: https://github.com/brigade/scss-lint
[from Sass-Guidelines]: http://sass-guidelin.es/#scss-lint
[Sass-lint]: https://github.com/sasstools/sass-lint
[LeadingZero]: https://github.com/brigade/scss-lint/blob/master/lib/scss_lint/linter/README.md#leadingzero
[BorderZero]: https://github.com/brigade/scss-lint/blob/master/lib/scss_lint/linter/README.md#borderzero
[scss-lint-regex]: https://github.com/HugoGiraudel/scss-lint-regex
[SMACSS]: https://smacss.com/
[7-1]: http://sass-guidelin.es/#the-7-1-pattern
[ITCSS]: https://speakerdeck.com/dafed/managing-css-projects-with-itcss
[vendor_ folder]: http://sass-guidelin.es/#vendors-folder
[npm]: https://www.npmjs.com/
[Bundler]: http://bundler.io/
[abstracts_ folder]: http://sass-guidelin.es/#utils-folder
[base_ folder]: http://sass-guidelin.es/#base-folder
[layout_ folder]: http://sass-guidelin.es/#layout-folder
[components]: http://sass-guidelin.es/#components-folder
[this tweet from Nicolas Gallagher]: https://twitter.com/necolas/status/251089236873338881
[check the spec]: https://www.w3.org/TR/css3-background/#the-border-color
[Git]: https://git-scm.com/
[https_www.sitepoint.com_cleaning-up-a-css-codebase]: https://www.sitepoint.com/cleaning-up-a-css-codebase/