# Topic 43 - 44
###### tags: `The Pragmatic Programmer`

[TOC]

## Topic 43. Stay Safe Out There (security)

> Good fences make good neighbors.

### The other 90%

When your code works, analyze and test the code further for ways it can go wrong, for example, passing in bad parameters.

### Security basic principles

> keep it simple and minimize attack surfaces

#### 1. Minimize attack surface area

What listed below are attack vectors

##### 1. Code complexity
##### 2. Input data
##### 3. Unauthenticated services: data which could be accessed by everyone are insecure.

##### 4. Authenticated services: keep the number of authorized users at an absolute minimum.

##### 5. Output data/debugging info: error message could include secure information like user id. Make sure those are safe.

#### 2. Principle of least privilege: design with less privilege if there is no need.

#### 3. Secure defaults

Let each individual decide for themselves the trade-offs between security and convenience (hide the password input or not).

#### 4. Encrupt sensitive data

Keys and secrets should not be version-controlled.

**Password antipatterns**


#### 5. Maintain security updates

- Ask yourself if security patches still work when systems are upgrading.

- Apply security patches quickly: most critical breachs in history happened because of security updates.

### common sense vs. crypto

Never do it youself: sophisticated algorithms work better.

## Topic 44. Naming things

> The beginning of wisdom is to call things by their proper name

Example: deductPercent() vs applyDiscount()


- 1. `Why it does?` vs `What it does?`
- 2. The parameter name `amount` is ambigious and misleading.

### 1. Honor the culture

It would be better to employ common used convention, for example, single letter variable like `i, j…`, and programming case types, etc.

### 2. Consistency

Sometimes record glossaries on Wiki might help.

### 3. Renaming is even harder

- It is encouraged to rename what has losen its intention.
- Spot overly generic name.