Quick Elaboration: What is "hard coding" and "soft coding"?

[NullInfinity]

Simple question. Wikipedia provides the following definition for hard coding:

Hard coding (also, hard-coding or hardcoding) refers to the software development practice of embedding what may, perhaps only in retrospect, be regarded as input or configuration data directly into the source code of a program or other executable object, or fixed formatting of the data, instead of obtaining that data from external sources or generating data or formatting in the program itself with the given input.

I'm not sure if I understand the definition. Is this basically the exact same thing as using a "magic constant?" or does it it apply to more situations?

Same with softcoding. Is it merely avoiding "magic constants" and defining const variables so that sudden changes to the program can cascade down, or is there more to it?

Thanks in advance, as always.

[JLBorges]

> Is this basically the exact same thing as using a "magic constant?"

To me, hard coding also applies to behaviour written directly into code,such that a change in policy would require modification of the code; supporting different policies would require different components.

Not hard coded:

namespace std
{
    template< typename CHAR_TYPE, 
              typename TRAITS_TYPE = std::char_traits<CHAR_TYPE>, 
              typename ALLOCATOR = std::allocator<CHAR_TYPE> > 
    class basic_string ; // policy is not hard-coded
}

Hard coded:

class my_string   // hard coded policy
                  // holds a sequence of single byte chars, 
                  // string comparisons are case sensitive, 
                  // memory is allocated using new[]
{
      my_string( const char* ) ; // no provision to specify policy at run-time
      // ...
};

[xismn]

Hardcoding things isn't always bad, either. For instance, you could hardcode a look up table instead of calculating values at run-time - I guess you could call those magic constants.

[NullInfinity]

Thanks Jorge Luis Borges!

What precisely do you mean by policy, and are there any prerequisite concepts for understanding what a policy is?

I glanced at these, but they only confused me further:

http://stackoverflow.com/questions/14718055/what-is-the-difference-between-a-trait-and-a-policy

http://en.wikipedia.org/wiki/Policy-based_design

EDIT: Thanks xismn!

[JLBorges]

> What precisely do you mean by policy,
> and are there any prerequisite concepts for understanding what a policy is?

It is a general (and therefore somewhat vague) concept. The idea is that many components involve two aspects: infrastructure (which is relatively stable, less likely to change over time), and policy (the 'logic'
which uses the infrastructure, something that is expected to be easily changeable). A few examples may help:

The main entrance to a building is infrastructure; the time at which an office remains open is policy.

The X11 server (protocol and graphics primitives) provides infrastructure, the desktop environment (what happens when I double-click on the title bar) specifies policy.

The Windows kernel implememnts infrastructure, lsass.exe is a user mode process that provides security policy.

The strategy design pattern is an example of the principle: achieve greater flexibility by separating policy from infrastructure, and allow policy and infrastructure to vary independently of each other.
http://www.oodesign.com/strategy-pattern.html

http://www.cplusplus.com/forum/general/125230/


> For instance, you could hardcode a look up table instead of calculating values at run-time

Even when a look up table is used, the programmer has a choice: whether or not to hard code its contents.

But, yes; hardcoding things isn't always bad.
Mercifully, cplusplus.com doesn't seem to have a hard-coding is 'evil' article as yet.

[NullInfinity]

Thanks again JLB.

I was gonna reply an hour ago, but life stuff happened.

It's really cool that you used Strategy design pattern as an example, because I just learned about it for the first time the other day while reading Elements of Reusable Object Oriented Software by Erich Gamma et al.

That article you linked to is (practically) verbatim from the book, and it's good to know that the terms "infrastructure" and "policy" are in that case interchangeable with "client" and "algorithm."

My book is from the mid 90s, though. So maybe I should start using that site to supplement it. :P

I'll mark as solved, but any extra feedback is appreciated!