Even a complex system can be written in a simple way. This site is a collection of ideas which dramatically decrease programming complexity by making the code clearer, more understandable and less confusing. It also describes some important defensive programming techniques. All that results in quicker development and easier maintenance/enhancement. And less bugs. And less frustration on bug investigations. In other words, it provides an easier life for the employee and huge cost savings for the employer.
During my career, I have modified and enhanced many existing applications. While working with kilometers of code written by other people, I noticed a curious fact: many programmers usually make the same typical mistakes! And although some of these mistakes are quite serious, the good news is that the list of them is actually small. So if someone decides to make their life easier by improving their coding style, it will require very little effort. Hopefully, the ideas presented on this site will help with that. They are illustrated with code examples in Java, PL/SQL and T-SQL, but they will be easily understood by users of any programming language. The most important stuff is highlighted with red color. Good luck!
• Coding Style
The art of naming
Over-indenting is the enemy number one
Code blocks must be short
Code after validations
Keep functions simple
Avoid code duplication
Store returned values in variables; avoid complex nested expressions
Defensive programming. Defuse time bombs!
Declare variables with as narrow scope as possible
Avoid too many arguments
Application codes
No loop condition duplicating
/* Comments */
Private and public affairs in instance variables
Private and public affairs in functions
Law of Demeter (or Principle of Least Knowledge)
• Intriguing World of Logic
Short conditions in IFs
Boolean functions
Use the NOT operator as little as possible
Positive comparison in Boolean expressions
Positive wording in Boolean names
Replace conditional with polymorphism
Populating Boolean variables
Don't return null from Boolean functions
Short-circuit evaluation
Boolean flags naming
Comparing ONE value with MANY others
• Ocean of Databases
Only single-field, surrogate primary keys
Simple SQL
Make sure the correct number of records is affected
Avoid client-side SQL - call stored procedures instead
Existence checking
Encapsulate each SQL statement in a dedicated function/proc
OUTER JOIN: only LEFT
Centralize TYPE definitions in one package (Oracle)
Avoid hard-coded exposure of error handling (Oracle)
Mention fields names in INSERT statement (SQL Server)
Temp table in stored proc (SQL Server)
Debugging T-SQL stored procedures without debugger
Tips and Tricks for developers in particular languages:
• Kotlin / Android / SQLite:
Generic class with SQLiteDatabase CRUD functions
Extend Cursor interface and ContentValues class
Convenient access to application's SharedPreferences
Create application settings (preferences) screen
Populate multi-values Preferences from constants
Create menu
Persistent Chronometer, keeps counting after restart
Listen to time changes in Chronometer
Convert date/time related types to String and back
Create instance (call constructor) of generic type
arrayOfNulls() with generic type
Change application language on fly (in runtime)
• PowerBuider:
DataWindow spy
Power building with exceptions
Access inter-objects parameters by name
Passing parameters between objects
iif()
iin() + global functions overloading
IfNull()
Avoid row-by-row scanning
Don't implement functionality in built-in events
Copy data between DWs/DSs
Check if column/row has REALLY been modified
Constants serving local needs
Constants used all over the application
Use constants always
Null constants
Oracle packaged procedure as DW data source
How to overcome long-circuit evaluation
Convert DW to... zebra!
Save DataStore from debugger
uf_ds_from_sql() to create DataStore by dynamic SELECT
uf_in_clause_from_array() to build SQL's IN clause dynamically
uf_ds_from_array() to convert array to DataStore
uf_add_unique_element_to_array()
uf_protect_col() for smart column protection
uf_row_exist() to replace Find()
uf_filter() to replace Filter()
uf_show_columns() to show only certain columns in DW
uf_set_row_status() to replace SetItemStatus()
uf_lookup_display() to obtain DropDown's display value
uf_value_exists_in_array() to check if array has a value
uf_get_field_label()
uf_display_in_center() to group buttons in the middle
uf_destroy() to POST objects' Destroy
uf_get_pb_version() to report PowerBuilder's version
uf_replace_all() to replace all occurrences of substring
CHOOSE CASE TRUE for a series of validations
Indentation in CHOOSE CASE
Change objects' default names
Technical code vs. business code
Return policy
Local Variables Declaration
Use REF keyword
Make DYNAMIC calls safer
Change default access level of class members
No global variables and functions
Avoid SQL in PowerBuilder
Don't duplicate conditions in Boolean expressions
Populate a DrpDownListBox with years
From the book "97 Things Every Programmer Should Know":
It doesn't take Sherlock Holmes to work out that good programmers write good code. Bad programmers - don't. They produce monstrosities that the rest of us have to clean up. You want to write the good stuff, right? You want to be a good programmer.
Good code doesn't pop out of thin air. It isn't something that happens by luck when the planets align. To get good code, you have to work at it. And you'll only get good code if you actually care about good code.
Good programming is not born from mere technical competence. I've seen highly intellectual programmers who can produce intense and impressive algorithms, who know their language standard by heart, but who write the most awful code. It's painful to read, painful to use, and painful to modify. I've seen more humble programmers who stick to very simple code, but who write elegant and expressive programs that are a joy to work with.
Based on my years of experience in the software factory, I've concluded that the real difference between adequate programmers and great programmers is this: attitude. Good programming lies in taking a professional approach, and wanting to write the best software you can, within the real-world constraints and pressures of the software factory.
The code to hell is paved with good intentions. To be an excellent programmer, you have to rise above good intentions, and actually care about the code - foster positive perspectives and develop healthy attitudes. Great code is carefully crafted by master artisans, not thoughtlessly hacked out by sloppy programmers or erected mysteriously by self-professed coding gurus.
You want to write good code. You want to be a good programmer. So, you care about the code:
1. You write code that is discoverable (that other programmers can easily pick up and understand), that is maintainable (that you, or other programmers, will be easily able to modify in the future), and that is correct (you take all steps possible to determine that you have solved the problem, not just made it look like the program works).
2. You work well alongside other programmers. No programmer is an island. Few programmers work alone; most work in a team of programmers, either in a company environment or on an open source project. You consider other programmers and construct code that others can read. You want the team to write the best software possible, rather than to make yourself look clever.
Fortunately, you're reading this collection of advice because you do care about code. It interests you. It's your passion. Have fun programming. Enjoy cutting code to solve tricky problems. Produce software that makes you proud.
It is currently 12 Oct 2024, 03:31
In total there is 1 user online :: 0 registered, 0 hidden and 1 guest (based on users active over the past 5 minutes)
Most users ever online was 479 on 03 May 2020, 12:22
Registered users: No registered users
Legend: Administrators, Global moderators
Total posts 174 • Total topics 128 • Total members 94 • Our newest member jagonzo62