8.
void HandleStuff( CORP_DATA & inputRec, int crntQtr, EMP_DATA empRec, double
& estimRevenue, double ytdRevenue, int screenX, int screenY, COLOR_TYPE &
newColor, COLOR_TYPE & prevColor, StatusType & status, int expenseType )
{
int i;
for ( i = 0; i < 100; i++ ) {
inputRec.revenue[i] = 0;
inputRec.expense[i] = corpExpense [crntQtr ][ i ];
}
UpdateCorpDatabase( empRec );
estimRevenue = ytdRevenue * 4.0 / (double) crntQtr;
newColor = prevColor;
status = SUCCESS;
if ( expenseType == 1 ) {
for ( i = 0; i < 12; i++ )
profit[i] = revenue[i] - expense.type1[i];
}
else if ( expenseType == 2 ) {
profit[i] = revenue[i] - expense.type2[i];
}
else if ( expenseType == 3 )
profit[i] = revenue[i] - expense.type3[i];
}
9. 선서
나는
프로그램 고수들을 나의 멘토로 모시고,
그들의 지혜를 경청하고 실천하여,
프로그래밍의 본질을 깨우쳐
프로그래밍의 전설적 고수가 되고자 합니다...
10. Define the problem completely.
If you don't understand it, you can't program it.
Without a good problem definition,
you might put effort into solving the wrong problem.
Be sure you know what you’re aiming at before you shoot.
11. Think first, Program lately.
Put the Mouse Down and Step Away from the Keyboard..
Throw away the keyboard !!
Fire, Aim, Ready ??
Look before leap.
Draw Diagrams !!
Think twice, code once.
Design first, then code.
12. Use the top-down approach.
Look at the whole picture !!
Draw Diagrams !!
13. Keep It Simple, Stupid! (KISS)
Keep it short and simple.
Occam's razor !!
Everything should be made as simple as possible,
but no simpler. - Albert Einstein
14. Don’t Repeat Yourself. (DRY)
Once And Only Once !!
Duplication is Evil (DIE).
Insanity: doing the same thing over and over again
and expecting different results.
15. Read The Fine Magazine. (RTFM)
Read The Fine Manual.
Read books, magazines, blogs, twitter feeds, and web sites.
Always try to work with a mentor.
If you can't find a mentor, consider moving on.
Go to conferences. Listen to podcasts.
Continuous Learning…
16. Understand the Art behind the Language.
Understand the philosophy of programming language.
Understand the culture of your programming language !!
Be aware of the specific strengths and weaknesses of the
language you’re using.
Choose the right programming language.
Don’t limit your programming thinking
only to the concepts that are supported
automatically by your language.
17. Divide and Conquer !!
Modern software is inherently complex.
Minimize the amount of essential complexity that anyone’s
brain has to deal with at any one time.
Don't Be Afraid to Break Things.
Keep accidental complexity from needlessly proliferating.
18. Modeling.
Without good software modeling, you may have the right problem
but the wrong solution.
It may be impossible to have successful construction.
Code is design.
Model-driven architecture: MVC Model
GoF: Design Patterns
19. Abstraction !!
Keep the level of the abstraction !!
Encapsulate all in the side .
Hide Secrets (Information Hiding).
Localize them.
Avoiding global data.
20. Single Responsibility.
Single Responsibility Principle:
a class should have one, and only one, reason to change.
Every piece of knowledge must have a single, unambiguous,
authoritative representation within a system.
-- Andy Hunt and Dave Thomas in The Pragmatic Programmer.
Single Source of Truth in model-driven architectures.
21. Defensive Programming
A clever person solves a problem. A wise person avoids it.
– Einstein
Be careful for Exceptions, Errors, Warnings,…
Make it fail-safe before you make it better.
Protecting Your Program From Invalid Inputs.
garbage in, nothing out / garbage in, error message out /
no garbage allowed in
Build Your Own Assertion Mechanism.
22. Automate Your Coding Standard.
Pretty Print (PP).
Style !! Layout !! Format !!
Hungarian notation by Charles Simonyi.
Use (naming) conventions.
23. Iterate, Repeatedly, Again and Again
Programming is neither fully an art nor fully a science.
As it’s typically practiced, it’s a “craft” that’s somewhere
between art and science. -- McConnell 2004
A first attempt might produce a solution that works,
but it’s unlikely to produce the best solution.
Don't be afraid to start over
25. Choose Your Tools with Care.
Right Programming Language and Right Tools !!
Design Tools // Source-Code Tools // Executable-Code Tools
Tool-Oriented Environments
Building Your Own Programming Tools
Discipline is the best tool.
26. Ask "What Would the User Do?"
You are not the User.
Use case analysis.
The User is the King. The user is Dummy.
User-Friendly.
27. Pieces of the advice
Never assume the computer assumes anything.
Don't patch bad code - rewrite it.
Make sure all variables are initialized before use.
Choose a data representation which makes the program simple.
Be sparing with temporary variables.
Parenthesize to avoid ambiguity.
Avoid side effects
Use library functions.
Choose a data representation which makes the program simple.
Test input for plausibility and validity.
28. Be Open Mind !!
Refuse to pretend you’re an expert when you’re not.
Readily admit your mistakes.
Get excited about programming !!
Open, Share, Communicate, and Cooperate !!
.