Defensive programming for better future AND NOW FOR
Defensive programming for better future
AND NOW FOR SOMETHING COMPLETELY DIFFERENT …
DEFENSIVE PROGRAMMING IGNORE IT, FIGHT IT, MOCK IT MY PERSONAL … JUST THINK ABOUT IT! VIEW
“DEFENSIVE PROGRAMMING” = A COLLECTION OF PROGRAMMING TECHNIQUES + A COLLECTION OF STYLE RECOMMENDATIONS https: //en. wikipedia. org/wiki/Defensive_programming
DEFENSE IN DEPTH
1. DATA CHECKING FIRST LINE OF DEFENSE 2. FUTURE PROOFING NEVER-SLEEPING GUARDS 3. READABLE CODE HELP YOUR FUTURE SELF
DATA CHECKING SANITIZE THE DATA!
DATA CHECKING SQL PARAMETERS BUFFER SIZE CHECKING FUNCTION RESULT CHECKING
FUTURE PROOFING SET UP GUARDS
MAINTAIN INVARIANT EXPEC PRECONDITION T DESIGN BY CONTRACT POSTCONDIT GUARANTEE ION http: //www. elementscompiler. com/elements/oxygene/language. aspx https: //en. wikipedia. org/wiki/Design_by_contract
PRECONDITION POSTCONDITION
USE DESCRIPTIVE ERRORS!
CHECK DATA EVEN WHEN IT CANNOT BE WRONG
“MILLION-TO-ONE CHANCES. . . CROP UP NINE TIMES OUT OF TEN. ” - TERRY PRATCHETT
“MILLION-TO-ONE CHANCES. . . CROP UP NINE TIMES OUT OF TEN. ” - TERRY PRATCHETT
CHECK DATA EVEN WHEN IT CANNOT BE WRONG ESPECIALLY THEN!
UNEXPECTED VALUES CAN … AND THEY WILL! APPEAR EXPECT THE UNEXPECTED! CASE ENUMERATI BE ALERT WHEN DEALING ONS CONSTANTS WITH ELSE IF CHAIN
UNSAFE! BETTER
ASSERT VS. RAISE VS. LOG WILL UNHANDLED UNEXPECTED VALUE HURT CUSTOMER? WILL THE POTENTIAL PROBLEM BE CAUGHT IN THE DEVELOP/TEST CYCLE?
“IT IS BETTER TO CRASH THAN TO CORRUPT THE DATA. ” - ME
“IT IS BETTER TO CRASH THAN TO CORRUPT THE DATA. ” - ME
PROGRAMMERS DO IT WITH TESTINSIGHT UNIT TESTS https: //bitbucket. org/sglienke/testinsight
UNIT TESTS • TEST ERROR PATHS!
WRITE READABLE CODE HELP YOUR FUTURE SELF
READABLE CODE = MAINTAINABLE CODE
READABLE CODE = MAINTAINABLE CODE
READABLE CODE = • GOOD DESIGN = GLOBAL STRATEGY • GOOD SEMANTICS= IMPLEMENTATION DETA = LOOK & UNDERSTAND • GOOD FORMATTING
“A GOOD DESIGN IS LIKE A GOODSingle HOUSE – DRY AND responsibility principle Don’t Repeat Open/closed Yourself SOLID. ”principle Liskov substitution principle - ME Interface segregation principle Dependency inversion principle
SO … WHAT IS GOOD CODE?
SIMPLER TASK: WHAT IS BAD CODE?
“SO I TOOK LITTLE BAD WITH A GOOD, IT AIN’T ALL BLACK AND WHITE …” - IGGY POP
“IT AIN’T THAT BAD!” (AT FIRST GLANCE)
KEVLIN HENNEY HE’S DA M AN! O LO I H K U M N O P U O Y ! E B U T
https: //github. com/gabr 42/Gp. Delphi. Code
“DON’T BE A SMARTASS!”
“AND WHO WILL SUPPORT THAT? ”
“DID YOU MEASURE IT? ” - ME
“DID YOU MEASURE IT? ” - ME
“BUT LOOK, IT IS SOOOO BEAUTIFUL!”
INSERT “MY DEITY < >, DOES THIS 1769 LINES! END? ” EVER
WHAT TO DO? TURN IT INTO A CLASS • LOCAL METHODS ⇒ CLASS METHODS • SHARED VARIABLES ⇒ CLASS FIELDS
STYLE GUIDE
“WE CAN'T EXPECT BAD PROGRAMMER TO WRITE GOOD COMMENTS. WE MAY BE ABLE TO FORCE THEM TO USE A CODING STYLE, THOUGH. ” - KEVLIN HENNEY
WHAT I CONSIDER BEAUTIFUL THESE DAYS
CODING STYLE SUGGESTIONS
SELF-DOCUMENTING IDENTIFIER NAMES I, J, K: INTEGER; ABSTRACTSINGLETONPROXYFACTORYBE TSIMPLEDSLCODEGEN. COMPILEBLOCK AN SYNCEDIT + REFACTOR
LONG PROCEDURES ARE BAD PREVIOUS EXAMPLE SHOULD BE >ENOUGH 1 SCREEN … ⇒ BAD < 1 SCREEN ⇒ GOOD
USE VARIABLES TO HOLD INTERMEDIATE VALUES
USE VARIABLES TO HOLD INTERMEDIATE VALUES
USE VARIABLES TO HOLD INTERMEDIATE VALUES
USE VARIABLES TO HOLD INTERMEDIATE VALUES
USE VARIABLES TO HOLD INTERMEDIATE VALUES
USE VARIABLES TO HOLD INTERMEDIATE VALUES
USE VARIABLES TO HOLD INTERMEDIATE VALUES
USE VARIABLES TO HOLD INTERMEDIATE VALUES
USE VARIABLES TO HOLD INTERMEDIATE VALUES MMX: ADD EXPLAINING VAR
MMX CODE EXPLORER IS NOW A FREE TOOL! WWW. MMX-DELPHI. DE
SIMPLE CASES FIRST
SIMPLE CASES FIRST
SIMPLE CASES FIRST
MATCH ALLOCATION/DEALLOCATION GETMEM / FREEMEM CREATE / DESTROY ACQUIRE / RELEASE
VISUALLY MATCH ALLOCATION/DEALLOCATION
VISUALLY MATCH ALLOCATION/DEALLOCATION
WITH? JUST SAY NO!
WITH? JUST SAY NO!
TREAT NUMBERS WITH SUSPICION
TREAT NUMBERS WITH SUSPICION
TREAT NUMBERS WITH SUSPICION
TREAT NUMBERS WITH SUSPICION
USE FIXINSIGHT http: //sourceoddity. com/fixinsight/
CODING ARCHITECTURE SUGGESTIONS
FREEANDNIL OR FREE? HOW ABOUT NONE? USE FREEANDNIL.
DON’T BE TOO SMART(ASS) WRITE THE SIMPLEST POSSIBLE CODE – YOU’LL BE GRATEFUL IN FIVE YEARS.
“CODE CAN BE A WORK OF ART – JUST DO IT AT HOME, NOT AT WORK. ” - KEVLIN HENNEY (PARAPHRASED)
“CODE CAN BE A WORK OF ART – JUST DO IT AT HOME, NOT AT WORK. ” - KEVLIN HENNEY (PARAPHRASED)
CODE TO THE INTERFACE
EXCEPTIONS DANGER, WILL ROBINSON!
W O I KN N A C HOW ? T CAN A TH LEAD TO A TERRIBLE DESIGN TFILESTREAM. CREATE DOC R EAD • NOTHING UM E T W N H T H ATIO E • EFCREATEERROR OD OES N ? • EFOPENERROR THA T
“EXCEPTIONS SHOULD NEVER CROSS API BOUNDARY. ” - ME
“EXCEPTIONS SHOULD NEVER CROSS API BOUNDARY. ” - ME
ACQUIREEXCEPTIONOBJECT RELEASEEXCEPTIONOBJECT
“EXCEPTIONS SHOULD NEVER CROSS THREAD BOUNDARY. ” - ME
“EXCEPTIONS SHOULD NEVER CROSS THREAD BOUNDARY. ” - ME
DON’T “EAT” EXCEPTIONS! ON ERROR RESUME NEXT TRY EXCEPT END;
CATCH THEM EXPLICITLY!
CATCH THEM EXPLICITLY!
CATCH THEM EXPLICITLY!
CATCH THEM EXPLICITLY!
OUR PRACTICE • CATCH AND LOG ALL EXCEPTIONS • EVEN HANDLED • UNLESS THEY ARE ANNOUNCED IN A SPECIAL WAY
OUR PRACTICE
USE EXCEPTION LOGGER • EUREKALOG • MADEXCEPT • JCLDEBUG
WRAPPING UP WHAT TO REMEMBER?
DON’T WRITE THE SAME CODE OVER AND OVER.
DON’T WRITE THE SAME CODE OVER AND OVER. TRY SOMETHING NEW. EXPERIMENT. LEARN. MAKE MISTAKES.
DON’T WRITE THE SAME CODE OVER AND OVER. TRY SOMETHING NEW. EXPERIMENT. LEARN. MAKE MISTAKES. EVOLVE.
A HUMAN BEING SHOULD BE ABLE TO CHANGE A DIAPER, PLAN AN INVASION, BUTCHER A HOG, CONN A SHIP, DESIGN A BUILDING, WRITE A SONNET, BALANCE ACCOUNTS, BUILD A WALL, SET A BONE, COMFORT THE DYING, TAKE ORDERS, GIVE ORDERS, COOPERATE, ACT ALONE, SOLVE EQUATIONS, ANALYZE A NEW PROBLEM, PITCH MANURE, PROGRAM A COMPUTER, COOK A TASTY MEAL, FIGHT EFFICIENTLY, DIE GALLANTLY. SPECIALIZATION IS FOR INSECTS. -ROBERT A. HEINLEIN
- Slides: 101
