Softcoding: Difference between revisions

Revision as of 07:08, 28 May 2009

Revision as of 03:58, 29 May 2009

Line 1:

'''Softcoding''' is a [[computer programming|computer coding]] term that meansrefers abstractingto obtaining a value or function intofrom asome containerexternal thatresource, issuch controllableas externala to[[preprocessor themacro]], mainexternal functionconstant, like a configuration file, databasecommand table,line argument or externaldatabase registrytable. TheIt term was coined asis the opposite of the existing term, [[Hardcodinghardcoding]], which refers to coding values and functions in the source code.

Avoiding hard-coding of commonly altered values is a good programming practice. Users of the software should be able to customize it to their needs, within reason, without having to edit the program's source code. Similarly, careful programmers avoid [[Magic number (programming)#Unnamed numerical constants|Magic Numbers]] in their code, to improve its readability, and assist maintenance. These practice are generally not referred to as 'softcoding'.

Line 5:

The term is generally used where Softcoding becomes an [[anti-pattern]]. Abstracting too many values and features can introduce more complexity and maintenance issues than would be experienced with changing the code when required. Softcoding, in this sense, was featured in an article on [[The Daily WTF]].<ref>[http://worsethanfailure.com/Articles/Soft_Coding.aspx Softcoding] from [[The Daily WTF]]</ref>.

At the extreme end, soft-coded programs develop their own poorly-designed and implemented scripting languages, and configuration files that require advanced programming skills to edit. This can lead to the production of utilities to assist in configuring the original program, and these utilities often end up being 'softcoded' themselves.

The boundary between proper configurability and problematic soft-coding changes with the style and nature of a program. Closed-source programs must be very configurable <!-- but generally aren't! -->, as the end user does not have access to the source to make any changes. In-house software and software with limited distribution can be less configurable, as distributing altered copies is simpler. Custom-built web applications are often best with limited configurability, as altering the scripts is seldom any harder than altering a configuration file. <!-- Witness the scores of CMS systems that are so much harder to work with than a bunch of html files in www/data! -->

To avoid 'softcoding', consider the value to the end user of any additional flexibility you provide, and compare it with the increased complexity and related ongoing maintenance costs the added configurability involves.