Anti Patterns - sgml/signature GitHub Wiki

• What it does:

  • Trades super fast
  • Uses lots of borrowed money
  • Buys and sells based on tiny price changes

• Why it goes wrong:

  • Can crash the market by accident
  • Gets confused by random price moves
  • Breaks if the computer is slow or buggy
  • Might break rules and get in trouble

• Real example:

  • A company lost hundreds of millions in minutes because of a broken trading program

• What it does:

  • Trades very slowly
  • Uses old price averages to guess future prices
  • Doesn't change when the market changes

• Why it goes wrong:

  • Misses big changes like pandemics or inflation
  • Holds bad trades too long
  • Makes very little money
  • Thinks old patterns will always work

• Real example:

  • Some funds using only old data stopped making money and quietly shut down

• Speed:

  • Aggressive: Super fast
  • Conservative: Very slow

• Risk:

  • Aggressive: Very risky
  • Conservative: Very safe but not smart

• What breaks it:

  • Aggressive: Computer glitch or weird market move
  • Conservative: Big world changes or surprises

• What happens:

  • Aggressive: Huge loss really fast
  • Conservative: Small losses over time

• Easy to understand:

  • Aggressive: Hard to explain
  • Conservative: Easy to explain but misses stuff

• Can it survive:

  • Aggressive: Breaks under pressure
  • Conservative: Gets left behind

• Skipping the Red phase
  Writing code before writing a failing test breaks the core cycle of TDD (Red -> Green -> Refactor)

• Writing overly broad or vague tests
  These fail to guide implementation and miss edge cases, leading to false confidence

• Neglecting refactoring
  Skipping the cleanup phase results in bloated, fragile code that's hard to maintain

• Treating tests as documentation only
  Tests should drive design, not just verify behavior after the fact

• Mocking everything
  Excessive use of mocks and stubs can lead to brittle tests and obscure real integration issues

• Coupling tests too tightly to implementation
  This makes refactoring painful and discourages design evolution

• Writing tests after code
  This reverses the TDD flow and often leads to shallow coverage

• Ignoring test failures
  Treating broken tests as noise undermines the entire discipline

• Using generated or boilerplate tests
  These often lack intent and don't reflect real usage scenarios

• Thread blindness
  In email, replies stack and bury the original message. Without a clear subject or summary, it vanishes.

• Scroll fatigue
  In IRC or RCS, long messages get skipped or fragmented by other replies.

• No affordance for skimming
  People scan for bolded text, bullets, or keywords. A wall of text offers none.

• No audit trail
  If you don’t timestamp or label your message, it’s hard to reference later.

• No subject line or vague subject

• No headers, bullets, or spacing

• No call to action or summary

• Buried links or attachments

• No timestamp or context

• Spreadsheet Used in 1933 Murder Mystery Novel

• Excel Project Management Templates – Spreadsheet Point

• Using Excel for Project Management – ExcelDemy

• 38 Excel Templates for Project Management – ProjectManager.com

• Apples to Apple Pie (piecemeal products)
• Apples to Rotten Apples (legacy products)
• Apples to Grapes (unscalable products)

1. Tunneling Everything Through GET: Using GET requests for operations that should be POST, PUT, or DELETE.
2. Ignoring Caching: Not leveraging HTTP caching mechanisms, leading to unnecessary server load.
3. Misusing Cookies: Using cookies for purposes other than authentication and session management.
4. Ignoring Response Codes: Not using HTTP status codes properly to indicate the result of an operation.
5. Breaking Self-Descriptiveness: Using URIs that don't clearly describe the resource or action.

1. Overly Complex WSDLs: Creating overly detailed and complex WSDL (Web Services Description Language) files that are hard to understand and maintain.
2. Ignoring Security: Not implementing proper security measures, such as encryption and authentication.
3. Tight Coupling: Creating tightly coupled services that are difficult to change or extend.
4. Poor Error Handling: Not providing meaningful error messages or handling errors gracefully.

1. Nullable Fields by Default: Allowing fields to be nullable by default, which can lead to unexpected null values.
2. Miscommunication in Docs: Poor documentation that leads to misunderstandings about the schema and its usage.
3. Lengthy Arguments to Mutations: Overloading mutations with too many arguments, making them hard to use and maintain.
4. Overfetching Data: Returning more data than the client needs, leading to inefficiency.

1. Ignoring Protobuf Best Practices: Not following best practices for defining Protobuf messages, leading to inefficient data structures.
2. Tight Coupling Between Services: Creating services that are too tightly coupled, making them hard to evolve independently.
3. Poor Error Handling: Similar to SOAP, not providing meaningful error messages or handling errors properly.
4. Overuse of Streaming: Using streaming unnecessarily, which can add complexity and overhead.

• Event based cache invalidation that fails silently

• Time based cached invalidation that is not based on UTC

• https://www.tutorialspoint.com/difference-between-cache-and-buffer

• Testing for specific strings rather than making sure key/value pairs are not undefined

• Testing for numbers rather than boolean values

• Testing for a specific date rather than an object that can be used by the date constructor

https://blog.softwaremill.com/the-case-against-annotations-4b2fb170ed67

https://dzone.com/articles/java-annotations-are-a-big-mistake

https://www.oracle.com/technetwork/java/javase/9-notes-3745703.html

https://mithril.js.org/components.html#avoid-anti-patterns

https://pythonrants.wordpress.com/2013/12/06/why-i-hate-virtualenv-and-pip/

https://cordova.apache.org/howto/2018/02/02/cordova-simulate.html

https://reactjs.org/blog/2015/12/16/ismounted-antipattern.html

https://americanexpress.io/faccs-are-an-antipattern/

https://cdb.reacttraining.com/use-a-render-prop-50de598f11ce

https://github.com/facebook/react/blob/master/packages/react-dom/src/__tests__/ReactDOM-test.js

https://www.w3.org/2001/tag/doc/promises-guide#when-not-to-use

https://www.w3.org/2011/04/webrtc/wiki/images/9/97/ModernWebRTC.pdf

http://www.cse.psu.edu/~trj1/cse544-f15/docs/aeg-current.pdf

https://www.tonymarston.net/php-mysql/object-relational-mappers-are-evil.html

http://www.scielo.org.co/pdf/rfiua/n80/0120-6230-rfiua-80-00097.pdf

https://blog.jooq.org/2014/09/12/why-you-should-not-implement-layered-architecture/

https://blog.rapid7.com/2016/06/23/r7-2016-06-remote-code-execution-via-swagger-parameter-injection-cve-2016-5641/

https://en.wikipedia.org/wiki/Coding_by_exception

https://softwareengineering.stackexchange.com/questions/118788/is-using-nested-try-catch-blocks-an-anti-pattern

https://doc.lagout.org/programmation/Pragmatic%20Programmers/SQL%20Antipatterns.pdf

Dependency injection is not effective if:

• You will never need a different implementation.

• You will never need a different configuration.

If you know you will never change the implementation or configuration of some dependency, there is no benefit in using dependency injection.

https://r.je/oop-courier-anti-pattern

Decouple computations from conditional logic. For example, instead of:

<xsl:if test="name() = 'foo'"> 

Do:

<xsl:variable name="cname" select="name() = 'foo'"/>
<xsl:if test="$cname">

I do not have to spend time in writing code to validate user input before its gets written to the database as that is handled by a standard framework component which matches each column's value with its data type which was exported from the Data Dictionary.

I do not have to spend time in designing mechanisms to handle domain-specific logic as the methods inherited from the abstract table class already implement the Template Method Pattern by providing a series of invariant methods with concrete implementations interspersed with empty hook methods into which the developer can insert custom logic.

I do not have to spend time in designing custom Controllers which call methods which are specific to individual Model classes as the framework provides a series of reusable Controllers each of which calls generic public methods which are defined in the abstract table class. There is a different Controller provided for each Transaction Pattern. This design allows me to pair any Controller with any Model/Table class.

Each event/task within the application performs a series of operations on a database table, and as there are different tasks which perform identical operations on different database tables I have managed to encapsulate the common code into a series of reusable Transaction Patterns. A facility within my Data Dictionary allows tasks to be generated by linking a particular table class with a particular pattern.

https://www.xml.com/pub/a/2003/07/02/xslt2.html

https://courses.ischool.berkeley.edu/i290-14/s05/lecture-5/allslides.html

http://www.microhowto.info/howto/refer_to_the_value_of_a_stylesheet_parameter_in_xslt.html

http://rcpconsulting.biz/whwItKb.html

https://www.slideshare.net/BarryOSullivan18/design-patterns-the-good-the-bad-and-the-antipattern

https://news.ycombinator.com/item?id=4549544

https://blog.frankel.ch/are-you-guilty-of-overengineering/

https://www.smashingmagazine.com/2016/03/pagination-infinite-scrolling-load-more-buttons/

https://logrocket.com/blog/infinite-scroll/

https://www.justinmind.com/blog/4-ux-friendly-alternatives-to-infinite-scroll/

https://uxplanet.org/ux-infinite-scrolling-vs-pagination-1030d29376f1

https://ux.stackexchange.com/questions/106514/should-i-use-regular-pagination-or-infinite-scroll-in-this-case

https://ux.stackexchange.com/questions/33406/infinite-scroll-vs-pagination-in-e-commerce-websites

https://news.ycombinator.com/item?id=7048474

https://www.reddit.com/r/userexperience/comments/8d1ajo/why_doesnt_google_implement_infinite_scroll_to/

Decouple operations into separate mutations to mitigate timeout issues

hardcoded_hell_in_wordpress:
  - pattern: "Embedding Static Text Instead of Using Translations"
    bad_practice: "<h1>Welcome to My Website</h1>"
    better_practice: "<?php echo esc_html__('Welcome', 'my-theme'); ?>"
  
  - pattern: "Hardcoded Links Instead of Dynamic Routing"
    bad_practice: "<a href='/about-us'>About Us</a>"
    better_practice: "<?php echo esc_url(get_permalink(get_page_by_path('about-us'))); ?>"
  
  - pattern: "Ignoring WordPress Widgets and Hardcoding Sections"
    bad_practice: |
      <div class="sidebar">
        <p>This is my sidebar content.</p>
      </div>
    better_practice: "<?php if (is_active_sidebar('sidebar-1')) { dynamic_sidebar('sidebar-1'); } ?>"
  
  - pattern: "Using Raw HTML Instead of Template Variables"
    bad_practice: |
      <div class="user-profile">
        <p>Name: John Doe</p>
      </div>
    better_practice: "<?php echo esc_html(get_the_author()); ?>"
  
  - pattern: "Hardcoded Styles Instead of Theme CSS"
    bad_practice: "<div style='color: red; font-size: 18px;'>Warning!</div>"
    better_practice: "Use theme stylesheets and enqueue styles via functions.php"