# UKAEA RSE Team Journal Club: 06/06/2024

:::info
- **Location:** Usual
- **Date:** 06/06/2024
- **Article Link:** https://quuxplusone.github.io/blog/2022/01/23/dont-const-all-the-things/
- **Agenda** *TODO*
1. Brief intro `2 min`
2. Discussion `43 min`
- **Participants:**
-
- **Host:** Chris

:::

## Brief Intro

Found blogpost through clang lints.

CM: A priori should use const wherever possible

Article says:

- Pass by const reference is good
- Pass by non-const reference is bad
- Suggests pass by pointer to make calling code clearer that object can be modified

## Discussion

### General

- JN: Following consistent conventions make code easier to read
- CM: Application across the board too restrictive
- KC: Common problem is unable to move out of const, Rust fixes this with borrow checker
- SP: Const should be on the right

### Struct member variables const

- Article discourages const member variables
- Const member variables prevents reassignment of member variables or instances of that class
- Article suggests "const" member variables should instead not have a setter
- HS: Use struct for data records and classes with getters/setters for "OOP" classes
- CM: Protecting mutability of variables via API is hard to manage for large classes
- CM: Big classes aren't assigned

### Local variables const

- JN: Too many keywords in C++ code, no performance benefit
- JP: Can prevent implicit move when return value optimization fails

### Const return value

- CM: generally no good reason to do this
- KC: exception code example: if ((a*b)=c) {}
- if operator* returns non const value this code which should have == compiles
- type needs to be implicitly convertable to bool
- Should be caught by compiler/linter
- from Scott Meyers Effective C++

### Consensus

- No real consensus
- C++ could be better