[benlesh]

It's a good article, but a good portion of these aren't "mistakes" but rather "opinions".

#1 isn't a "mistake" it's a preference, really. Also, I'm really not sure about putting the template files in the directory with the other files. Then I guess I'd have to add something to my build script to copy them to a hosted directory?

#3.1 IMO, Is actually more of a mistake. Imagine you have 3-4 modules, which one do you define that underscore service in? Oops, better make a 5th "common" module, I guess. Just to include something that you could have injected with $window. Notably, the underscore service is also missing that it should be injecting $window. How is he going to test that? Scrap the whole underscore service, and just inject $window where you need something from the global scope.

#9.1 Protractor - Protractor is great. But it's a little hefty for true "unit" tests. Jasmine with `angular-mocks` works a little better for unit testing Controllers and Services, where Protractor is better at testing directives and full end-to-end tests.

and one thing I'd add to this list:

#11 - Overly "DRY" Jasmine tests.

A lot of Angular developers I know are way too fond of drying up their Jasmine tests with nested describe() blocks and lots of beforeEach() clauses. Tests should really be "DAMP" not "DRY".

[munro]

#1 -- Separating by concerns is much preferable to me, organizing by controllers/directives/services/... is a separation of technology, not the high level concept. There's a great React video on this concept, as well as some other good stuff! [1]

[1] https://www.youtube.com/watch?v=x7cQ3mrcKaY

[vectorpush]

> #11 - Overly "DRY" Jasmine tests.

Agreed. I've gone down that rabbit-hole myself more times than I'd like to admit. It's very easy to waste time DRYing up your test suite with beforeEach calls; there is a kind of nagging temptation to reduce every spec down to the minimum number of lines required, and it's a pretty cathartic way to avoid doing real work (especially if you're taking a TDD approach), but ultimately, you just end up constricting your test suite in a way that wastes even more time when the day comes that you have to adjust a few specs in a manner which is incompatible with the beforeEach templates you've established for the suite.

Nowadays, as a rule of thumb, if the tests are already passing, I forbid myself from refactoring any specs that test an unshipped feature. Maybe I should be a full time test engineer because it's really not a very healthy behavior. :)

[seivan]

Been there as well. I call it being clever with your test suites. Figuring out a way to hack your test suites so you can write as little code as you can. Except your test suite ends up unreadable because of all the magic you made for... DRY.

[tcopeland]

Yup, per Sandi Metz:

https://twitter.com/sandimetz/status/514411916480249856

I've also heard it expressed as "the pain caused by code duplication is nothing compared to the pain caused by wrong abstractions".

[niuzeta]

do you mind explaining the acronyms? DRY and DAMP sound more like a degree of wetness unless a definition is provided.

[benaiah]

DAMP?

[wtetzner]

Descriptive And Meaningful Phrases

https://stackoverflow.com/questions/6453235/what-does-damp-n...

[thisone]

as an industry, we really love those backronyms

[rybosome]

In this context, how about something like this?

"Don't repeat yourself (As Much as Possible)"