Application codes

Link to this posting

Postby Ursego » 21 Feb 2013, 12:10

Never hardcode application codes (like statuses, entities’ types etc.); instead, use constants or enumerations.

It’s always a good practice to create constants/enumerations for codes you mention in code, even if these codes used to be hardcoded in the application for years. Prefer the correct programming stile (with its elegance and maintainability), not bad traditions.

*** BAD code: ***

Code: Select all
if li_inv_status = 8 then...

Code: Select all
if (invStatus == 8)...

*** GOOD code: ***

Code: Select all
if li_inv_status = nv_inv_status.CANCELED then...

Code: Select all
if (invStatus == InvStatus.Canceled)...

For application codes, use mnemonic strings (like 'OPEN', 'CLOSED' and 'CANCELED') rather than meaningless numbers (like 1, 2, 3...) or too short strings (like 'O', 'C' and 'N').

Such self-explanatory codes make debugging and exploring data in DB tables much easier - developers don't need to look in the catalog tables to understand the meaning (and will not guess doing incorrect assumptions). These mnemonic strings don't need to be long - VARCHAR(10) is enough, we can always shorten words if needed still keeping them perfectly understandable.

But even having easily-readable codes, we still must use constants because hardcoding is bugs-prone: mistyping doesn't raise a compilation error .
User avatar
Site Admin
Posts: 113
Joined: 19 Feb 2013, 20:33

IF you want to ((lose weight) OR (have unbelievable (brain function AND mental clarity))) THEN click:

free counters

eXTReMe Tracker