By Michael Zuskin (LinkedIn)

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. The ideas, described here, dramatically decrease code complexity and make the code clearer, more understandable and less confusing. That results in quicker development and easier maintenance/enhancement. And less bugs. And easier bugs investigation and fixing.

Code elegance... Sounds nice, but is it really so important? Does it simplify the developer's work? Can it define a project's success? Can a lack of it contribute to a project's failure? All these questions have the same answer - yes. I believe that the most important component of business applications creators' work is understanding of the business, organization of data storage and processing, knowledge of OOP on the level of feeling, and expertise in GUI events. But code writing style is important as well - in fact, each aspect of the programmer's work (including code writing professionalism) plays a critical role. Even though coding style mistakes are looking insignificant, they are accumulating over time and, finally, quantity turns into quality. Even a small needle can blow up a big balloon!

I have seen programmers which came to development from the business sector. Usually they wrote code in a very straightforward way, without too much thinking (or even knowing?) about good coding practices. Unfortunately, I've also seen many bad coders with Computer Science / Software Engineering background. And that is not surprising at all! I myself never heard about elegant coding style in the nice days of college. But I am very lucky because, when I was a junior developer, I had very severe teachers - technical leads with zero tolerance to stupid things in my code. Later, working with complicated software, I always remembered these people with gratitude: they forced me to always think about optimal code organizing, and constantly use simple, but very useful tricks. Thanks to these people, I know that even complex systems can be written in a simple way.

Only 3.5 developers were occupied in one of the most large-scale projects I worked in (the PM, one other developer and me + sometimes fourth guy joined us to help before deadlines). The main reason for so high effectiveness was the use of a good framework library (so we thought mostly about "what" to develop - not "how", in other words - wrote minimum of technical code concentrating on business issues). And the second reason - the application was written using many rules described in this site. All applications in that company had elegant code, controlled by very strict and even ruthless code reviewers. On the other hand, I participated in enhancement of legacy applications which were much-much simpler from the user's perspective, but with much-much more people involved. Whole IT departments were struggling with tons of mixty-maxty, hopelessly labyrinthine code. Stupidity is much more expensive than cleverness: every year those companies spent huge amounts to pay salaries to extra workers only because the initial development was based on copypaste and long functions rather than smart refactoring of code, and without utilizing defensive programming – writing code which automatically raises alarms in case problems (to prevent bugs, which would be hard to detect and investigate, as early as possible), and so ensures foolproofing during the whole app life - from initial unit testing to future changes. This was especially insulting because correct coding does not require a great mind - it only requires knowledge of a few simple principles!

The ideas are illustrated with multiple code examples in Java and PowerBuilder (abbreviated as PB), sometimes in PL/SQL and T-SQL. But they will be clear and easily understood by developers, using any programming language.



• The Art of Naming:

Exact meaning
Consistency
Long, descriptive names
Abbreviations
Exact action timing




• Code Writing Style:

Over-indenting is the enemy number one <<< IMPORTANT!!!
Loops with CONTINUE
No loop condition duplicating
Avoid complex nested expressions
Store returned values in variables
Process impossible options (defensive programming) <<< IMPORTANT!!!
Application codes
/* Comments */
Private and public affairs in instance variables
Write RETURN in the end of void methods




• Managing Functions:

Keep functions simple <<< IMPORTANT!!!
Code blocks must be short
Code after validations <<< IMPORTANT!!!
Refactor to prevent duplication <<< IMPORTANT!!!
Private and public affairs in functions
Law of Demeter (or Principle of Least Knowledge)




• Intriguing World of Logic:

Boolean flags naming
Positive wording in Boolean names
Positive comparison in Boolean expressions
Comparing ONE value with MANY others
Short conditions in IFs
Boolean functions
Populating Boolean variables
Don't return null from Boolean functions
De Morgan's Laws
Short-circuit evaluation




• Ocean of Databases:

Only surrogate primary keys <<< IMPORTANT!!!
Simple SQL <<< IMPORTANT!!!
WHERE clause
OUTER JOIN: only LEFT
Mention fields names in INSERT statement (SQL Server)
Temp table in stored proc (SQL Server)
Existence checking
Avoid client-side SQL - call stored procedures instead <<< IMPORTANT!!!
Debugging T-SQL stored procedures without debugger

Next stuff is only for PowerBuider developers:




• Elegant Code:

Power Building with Exceptions <<< IMPORTANT!!!
Local Variables Declaration
CHOOSE CASE TRUE for a series of validations
Indentation in CHOOSE CASE
Change objects' default names
Technical code vs. business code
Return policy
Use REF keyword
Constants used all over the application
Constants serving local needs
Null constants
Change default access level of class members
Don't DESTROY objects
No global variables and functions
Avoid SQL
Don't duplicate conditions in Boolean expressions
Try to avoid DYNAMIC calls
Access inter-objects parameters by name
Avoid row-by-row scanning
Don't implement functionality in built-in events




• Tips and Tricks:

DW Spy <<< IMPORTANT!!!
Passing parameters between objects
iif()
iin() + global functions overloading
nvl()
Oracle packaged procedure as DW data source
How to overcome long-circuit evaluation
Populate Code Tables from constants
Convert DW to... zebra!
Save DataStore from debugger
Copy data between DWs/DSs
Check if column/row has REALLY been modified
uf_row_exist() to replace Find()
uf_filter() to replace Filter()
uf_set_row_status() to replace SetItemStatus()
uf_lookup_display() to obtain DropDown's display value
uf_destroy() to POST objects' Destroy
uf_get_pb_version() to report PowerBuilder's version
uf_replace_all() to replace all occurrences of substring
uf_in_clause_from_array() to build SQL's IN clause dynamically
uf_ds_from_sql() to create DataStore by dynamic SELECT
uf_ds_from_array() to convert array to DataStore
uf_value_exists_in_array() to check if array has a value
uf_add_unique_element_to_array()
uf_get_field_label()
uf_display_in_center() to group buttons in the middle
uf_show_columns() to show only certain colums in DW

It is currently 26 Jun 2019, 05:06

  • Java
    11 Topics
    12 Posts
    Last post by Ursego View the latest post
    20 May 2019, 09:34

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 69 on 06 Nov 2018, 23:25

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

Statistics

Total posts 154 • Total topics 113 • 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:




free counters

eXTReMe Tracker