Clean Code C# Lessons

By abdelrhman abdelaziz

CLEAN CODE & PROFESSIONALISM

01/13 ~/clean-code/intro.sh ./execute --mode learning CLEAN CODE & PROFESSIONALISM The Boy Scout Rule: Leave the campground cleaner than you found it. leblancs_law.txt # LeBlanc's Law Later equals never. > Transition from 'code that works' > to 'code that is maintainable.' ] [ abdelrhman abdelaziz @linkedin] ~ $

MEANINGFUL NAMES

02/13 ~/clean-code/naming.cs MEANINGFUL NAMES Names should reveal intent. If a name requires a comment, then the name does not reveal its intent. TimeTracker.cs // BAD: Magic numbers and obscure letters int d ; // elapsed time in days var list1 = new List < int >(); // GOOD: Intention-revealing and searchable int elapsedTimeInDays ; var flaggedCells = new List < Cell >(); _ [ abdelrhman abdelaziz @linkedin] ~ $

FUNCTIONS DO ONE THING

03/13 ~/clean-code/functions.cs FUNCTIONS DO ONE THING Keep them small. One level of abstraction per function. Extract methods until you can't. OrderService.cs public void ProcessOrder ( Order order ) { // Reads like a top-down narrative ValidateOrder ( order ); ChargeCustomer ( order ); UpdateInventory ( order ); NotifyFulfillment ( order ); } > [ abdelrhman abdelaziz @linkedin] ~ $

COMMENTS ARE A FAILURE

04/13 ~/clean-code/comments.cs COMMENTS ARE A FAILURE Express your intent in code. Comments lie, code doesn't. Reserve comments for legal notices or complex Regex. Eligibility.cs // BAD: Explaining messy logic // Check to see if employee is eligible for benefits if (( employee.Flags & HOURLY_FLAG ) != 0 && ( employee.Age > 65 )) { ApplyBenefits (); } // GOOD: Express intent with a named method if ( employee . IsEligibleForFullBenefits ()) { ApplyBenefits (); } } [ abdelrhman abdelaziz @linkedin] ~ $

FORMATTING MATTERS

05/13 ~/clean-code/formatting.sh FORMATTING MATTERS Code is read far more than it is written. Use vertical openness to separate concepts. Team rules beat individual preference. Dense / Unreadable Open / Grouped ] [ abdelrhman abdelaziz @linkedin] ~ $

LAW OF DEMETER

06/13 ~/clean-code/objects.cs LAW OF DEMETER Objects hide their data and expose behavior. Don't reach through objects to get to other objects (Train Wrecks). TrainReservation.cs // BAD: Train Wreck (Coupled to internal structure) var seat = train . GetCar ( 3 ). GetRow ( 12 ). GetSeat ( "A" ); seat . Reserve ( passenger ); // GOOD: Tell, Don't Ask train . ReserveSeat ( passenger , car : 3 , row : 12 , seat : "A" ); _ [ abdelrhman abdelaziz @linkedin] ~ $

EXCEPTIONS OVER NULLS

07/13 ~/clean-code/errors.cs EXCEPTIONS OVER NULLS Don't return null. Don't pass null. Returning null creates defensive programming clutter across your entire codebase. DeviceController.cs // BAD: Null checking disease DeviceRecord record = GetRecord (); if ( record != null ) { // do something } // GOOD: Throw Exceptions try { DeviceRecord record = GetRecord (); } catch ( DeviceNotFoundException e ) { // handle gracefully } ! [ abdelrhman abdelaziz @linkedin] ~ $

PROTECT YOUR BOUNDARIES

08/13 ~/clean-code/boundaries.sh PROTECT YOUR BOUNDARIES Keep 3rd party code at the boundaries. Use the Adapter pattern to isolate your core domain from vendor changes. SYSTEM BOUNDARY CORE_DOMAIN Business Rules Isolated & Clean OUR_ADAPTER Interface Wrapper Translates Data 3RD_PARTY_API External Vendor Prone to Change | [ abdelrhman abdelaziz @linkedin] ~ $

KEEP TESTS F.I.R.S.T.

09/13 ~/clean-code/tests.cs KEEP TESTS F.I.R.S.T. Fast, Independent, Repeatable, Self-Validating, Timely. Test code is just as important as production code. BillingTests.cs [ Fact ] public void ApplyDiscount_WhenUserIsPremium () { // Arrange var user = new User { IsPremium = true }; var billing = new BillingService (); // Act var total = billing . CalculateTotal ( user , 100 ); // Assert Assert . Equal ( 80 , total ); } ✓ [ abdelrhman abdelaziz @linkedin] ~ $

HIGH COHESION, LOW COUPLING

10/13 ~/clean-code/classes.cs HIGH COHESION, LOW COUPLING Classes should be small. Depend on abstractions (interfaces), not concrete implementations (Dependency Inversion). OrderProcessor.cs public class OrderProcessor { private readonly IEmailService _email ; // Injected via constructor public OrderProcessor ( IEmailService email ) { _email = email ; } } < [ abdelrhman abdelaziz @linkedin] ~ $

SEPARATE CONSTRUCTION FROM USE

11/13 ~/clean-code/systems.cs SEPARATE CONSTRUCTION FROM USE The startup process is a separate concern. Use Dependency Injection (DI) containers to resolve dependencies centrally. Program.cs var builder = WebApplication . CreateBuilder ( args ); // Centralized Construction builder . Services . AddScoped < IOrderService , OrderService >(); builder . Services . AddTransient < IEmailService , SmtpEmail >(); var app = builder . Build (); app . Run (); ~ [ abdelrhman abdelaziz @linkedin] ~ $

4 RULES OF SIMPLE DESIGN

12/13 ~/clean-code/emergence.sh 4 RULES OF SIMPLE DESIGN Clean code is not written; it is refactored into existence. Prioritize these rules in order: 1 Runs all the tests. A system that can't be verified shouldn't be deployed. 2 Contains no duplication. Duplication is the root of all evil in software. 3 Expresses intent. Make it easy for the next programmer to understand. 4 Minimizes classes & methods. Keep the overall size small, but only after applying 1-3. + [ abdelrhman abdelaziz @linkedin] ~ $

WHICH PRINCIPLE CHANGED YOUR CAREER?

13/13 ~/clean-code/discussion.sh ./shutdown -h now WHICH PRINCIPLE CHANGED YOUR CAREER? Clean code is an ongoing practice of professional craftsmanship. input.sh ? Enter your answer in the comments: > [ abdelrhman abdelaziz @linkedin] ~ $

1 / 13