
Anti Patterns Catalog - infogulch
http://wiki.c2.com/?AntiPatternsCatalog
======
paulddraper
Anti-pattern: GasolinePoweredFlySwatter

Reaching for heavy and complex tools when a straightforward solution would
have sufficed.

Example: Requiring JavaScript for a simple static site. Making a wiki as an
SPA.

~~~
joncp
Came here to say this. Does anyone know whether there's an effort to port this
to a sane wiki system?

~~~
imode
[http://imode.gitlab.io/projects/c2/index.html](http://imode.gitlab.io/projects/c2/index.html)

here's a dump of the entire wiki in WikiWikiWeb markup. if you can do anything
with it, let me know.

~~~
vmorgulis
What do you think of Pandoc? [http://pandoc.org/](http://pandoc.org/)

The two supported wiki markups:

\- MediaWiki
[https://www.mediawiki.org/wiki/Help:Formatting](https://www.mediawiki.org/wiki/Help:Formatting)

\- TWiki [http://twiki.org/cgi-
bin/view/TWiki/TextFormattingRules](http://twiki.org/cgi-
bin/view/TWiki/TextFormattingRules)

I wonder which one is the closest to WikiWikiWeb syntax.

Another cool stuff would be to put that in the gopherspace.

~~~
imode
I actually tried pandoc + MediaWiki markup but it ended up quite consistent
and not representing the original page.

ward's site actually contains the rules for deconstructing the JSON and
translating it to HTML. I'll have a look at that when I have time.

------
justicezyx
My experience shows that almost all GoF design patterns, except singleton, are
not useful at all in writing _modern_ C++ software.

The singleton is really just about a language trick, it hardly means anything
more than a global variable fit into C++'s class hierarchy.

I've been writing C++ in the past 1.5 years. All I have saw is design patterns
being used forcefully and awkwardly. And there has not been a single instance
where a pattern is used and improves the overall quality.

Such practices result into closely coupled class webs, which is hostile to
testing, extremely difficult to understand and change; the worst, they easily
causes circular dependency, which was once considered a norm in C++ code.

They also result into overengineerred interfaces, which gradually morphed into
a "DoEverything" interface, like DoEverything(ActionOptions,
RuntimeEnvironment). ActionOptions literally captures every options you can
have on anything; and RuntimeEnvironment includes all data for the action to
happen.

IMHO, C++ code is about as good as it can be, when it manages to achieve 2
things: 1\. DAG in translation unit dependency. 2\. Predominantly prefer
composition to inheritance.

Plus, class access control (private/protected), and anonymous namespace should
not be used to hide your implementation. That makes writing tests way too
troublesome. And TBH, no one wants to abuse implementation details, unless the
interface is bad or no comprehensive tests.

~~~
novembermike
I never really got the whole public/private thing. If you want to only expose
certain functionalities, that's what the interface does. Making things private
just hides things that are potentially nice hooks for testing or whatever.

~~~
zvrba
> I never really got the whole public/private thing.

It's about encapsulation and class invariants. Public methods must preserve
them, private methods can break them temporarily. You get a prepackaged
component and you're prevented from introducing bugs into the component from
the outside of the component.

Take std::vector, for example. By keeping implementation details (pointer to
element storage and element count) private, you prevent users of the class to
accidentally shoot themselves in the foot by, say, changing the element count
directly.

You _could_ use interfaces, but for that you have to use virtual functions:
Objects have to be created dynamically and you have to handle pointers or
references instead of values.

~~~
novembermike
I understand what it's used for, i just feel like there's a more elegant way
to do it.

------
ThePhysicist
We published a small collection of Python-related anti-patterns a while ago
under a creative commons license, feel free to check it out:

[http://docs.quantifiedcode.com/python-code-
patterns/](http://docs.quantifiedcode.com/python-code-patterns/)

~~~
cakebrewery
Are those also considered anti-patterns, or simply "bad practices"? The
examples in the article seem to have a wider scale than the ones mentioned in
your collection.

My question is, where is the line the line between an anti-pattern or simply a
"bad practice", or if they are the same?

~~~
drivers99
anti-pattern would be: "commonly reinvented bad solution to a recurring
problem" (paraphrasing wikipedia)

~~~
webmaven
Anti-patterns can be copied as well as reinvented. Also, some can manifest
simply through developers' inattention rather than being a deliberate
reinvention, such as:

* Big Ball of Mud

* Creeping featuritis

* Copy Pasta

------
jpalomaki
[http://wiki.c2.com/?ReinventTheWheel](http://wiki.c2.com/?ReinventTheWheel)

[http://wiki.c2.com/?ReinventingTheWheel](http://wiki.c2.com/?ReinventingTheWheel)

[http://wiki.c2.com/?NotInventedHere](http://wiki.c2.com/?NotInventedHere)

~~~
jyriand
I guess there can be an antipattern opposite to NotInventedHere, where
developers don't want to solve small problems, only reuse existing libraries
that already address the problem in hand. I guess this is most noticeable in
the javascript world.

~~~
andreareina
I've seen it called "Never Invent Here"

------
badumpTissss
I feel like this list has been designed in such a way that it is not possible
to create any code, without implementing an example from the list.

When you make a list this long, you're attempting to cast a wide net over most
conditions, if not trying for total coverage by including catch-all buckets.

Meanwhile, it feels slightly impossible to ask anyone to write code at all,
without having them complain about _something_.

The only lesson I can glean from this is that every project requires a
compromise of combining abominations with idealized perfection, and that
transitory human moods and emotions have more effect on programming tastes,
than actual practicality.

~~~
cookiecaper
This is the case with most such lists of verboten practices. It's good to know
the general rules, but it's also important to know when your situation
justifies breaking them. Competency is all about good judgment.

------
tedunangst
[http://wiki.c2.com/?PassingNullsToConstructors](http://wiki.c2.com/?PassingNullsToConstructors)

Is it even worth having such pages in a wiki? Is this a catalog of
antipatterns or empty templates?

~~~
ccvannorman
I don't know which is funnier, the inaccessibility of the "anti-pattern"
website in general which is bitching about inaccessibility of applications, or
the fact that the 'constructor' (loosely) for serving you that page is clearly
'null'~

------
janwillemb
The wiki is very slow since the upgrade.

~~~
al2o3cr
At least it works now. There was a hot minute there where they'd decided that
the `fetch` API was a required feature and didn't polyfill it, totally
breaking the site in browsers that lacked the feature.

------
hasbot
What a mess of a list. Management, coding, architectural, and uncategorized
"anti-patterns" lumped together. I bet many of them are just from somebody
blowing off steam.

------
imode
shameless plug: there is an entire dump of the c2 wiki at
[http://imode.gitlab.io/projects/c2/index.html](http://imode.gitlab.io/projects/c2/index.html)

it's still in plaintext, i.e WikiWikiWeb markup format, and I haven't touched
it in a while. if anybody knows how to convert this to HTML, let me know and
I'll batch-convert it.

ward, your site is taking a down-hill turn. stop with this remodeling and go
back to the static site, please.

