Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
Tags
- change detection
- 변화감지
- 테두리굵기
- error
- Git
- ion-range
- Visual Studio Code
- rxjs
- IONIC3
- border-width
- ChangeDetectorRef
- Ionic
- getElementsByClassName
- Sentry
- code .
- sealize
- zsh
- VSCode
- hashchange
- NVM
- typescript
- 이미지바꾸기
- 자바스크립개념
- angular5
- aab 배포
- php
- angular
- oh-my-zsh
- JavaScript
- fromEvent
Archives
- Today
- Total
hsunny study blog
1.2 Expressions and Statements 본문
Indent to show structure.
BAD CASE
for(n++;n<100;field[n++]='\0');
*i = '\0'; return('\n');
GOOD CASE
for(n++; n<100; n++)
field[n] = '\0';
*i = '\0';
return '\n';
Even better is to put the assignment in the body and separate the increment,
so the loop takes a more conventional form and is thus easier to grasp.
Use the natural form for expressions.
Conditional expressions that include negations are always hard to understand.
BAD CASE
if(!(a < b) || !(b <= c))
GOOD CASE
if((a >= b)||(b > c))
Parenthesize to resolve ambiguity.
Break up complex expressions.
Be clear.
Be careful with side effects.
WORD
Parenthesize 괄호 안에 넣다
'book > The Practice of Programming' 카테고리의 다른 글
1.6 Comment (0) | 2015.12.28 |
---|---|
1.5 Magic Number (0) | 2015.12.24 |
1.4 Function Macros (0) | 2015.12.23 |
1.3 Consistency and Idioms (0) | 2015.12.22 |
1.1 Names (0) | 2015.12.21 |