<h3>Small! Really small</h3> <p>An entire function should rarely exceed 20 lines. If you need a comment to explain a block inside a function, extract that block into a new function.</p>
<div class="tip"> One assertion per test is a good guideline. If you have many, consider splitting. </div> codigo limpo epub
<h2>9. Concurrency: Keep It Simple</h2> <p>Concurrency adds complexity. Mitigate it:</p> <ul> <li>Keep synchronized sections small.</li> <li>Use immutable objects when possible.</li> <li>Document threading semantics.</li> <li>Test concurrency code aggressively with tools like ThreadSanitizer or JCStress.</li> </ul> <h3>Small
<h2>8. Unit Tests: First-Class Citizens</h2> <p>Tests must be kept as clean as production code. Follow the <strong>F.I.R.S.T.</strong> principles:</p> <ul> <li><strong>Fast</strong>: Run in milliseconds.</li> <li><strong>Independent</strong>: No test depends on another.</li> <li><strong>Repeatable</strong>: Same result in any environment.</li> <li><strong>Self-validating</strong>: Boolean output (pass/fail).</li> <li><strong>Timely</strong>: Written just before the production code (TDD).</li> </ul> If you have many, consider splitting
<h3>Rule 2: Avoid disinformation</h3> <p>Don't use <code>accountList</code> unless it’s actually a <code>List</code>. Prefer <code>accounts</code> or <code>accountGroup</code>.</p>
<h3>Rule 1: Use intention-revealing names</h3> <div class="bad"> <code>int d; // elapsed time in days</code> </div> <div class="good"> <code>int elapsedTimeInDays;</code> </div>
<h2>6. Error Handling: Separate Logic from Errors</h2> <p>Error handling is one thing. Your business logic is another. Don’t mix them.</p>