"Beauty will save the world"
Fyodor Dostoyevsky

"Beauty will save programming"
Michael Zuskin (LinkedIn)

Even complex systems 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 easier bugs investigation and fixing.

*** Click here to read the introduction ***


Dealing with tons of code written by others (while enhancing and changing existing systems), I noticed that programmers usually make the same typical mistakes. Even though some of the mistakes are pretty severe, the good news is that the list of them is quite short. So, if somebody will decide to facilitate their life by improving the coding style, that will require pretty small efforts. Hopefully, the ideas, presented in this site, will help in that. They are illustrated with code examples in Java, PL/SQL and T-SQL, but users of any programming language will easily understand them. 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 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

The rest of the stuff is for PowerBuider developers only. If you are not one of them, skip this section:



• PowerBuider Tips and Tricks

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":

You Gotta Care About the Code


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 22 Nov 2019, 20:07

  • Java
    13 Topics
    14 Posts
    Last post by Ursego View the latest post
    10 Sep 2019, 06:48

Login  •  Register

Who is online

In total there are 4 users online :: 0 registered, 0 hidden and 4 guests (based on users active over the past 5 minutes)
Most users ever online was 336 on 19 Nov 2019, 18:12

Registered users: No registered users
Legend: Administrators, Global moderators

Statistics

Total posts 163 • Total topics 115 • Total members 94 • Our newest member jagonzo62


Professional code inspectors at work:



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




cron
free counters

eXTReMe Tracker