Community hub
Hard coding
View on Wikipedia | This article needs additional citations for verification. (May 2021) |
Hard coding (also hard-coding or hardcoding) is the software development practice of embedding data directly into the source code of a program or other executable object, as opposed to obtaining the data from external sources or generating it at runtime.
Hard-coded data typically can be modified only by editing the source code and recompiling the executable, although it can be changed in memory or on disk using a debugger or hex editor.
Data that is hard-coded is best suited for unchanging pieces of information, such as physical constants, version numbers, and static text elements.
Soft-coded data, on the other hand, encodes arbitrary information through user input, text files, INI files, HTTP server responses, configuration files, preprocessor macros, external constants, databases, command-line arguments, and is determined at runtime.
Overview
[edit]Hard coding requires the program's source code to be changed any time the input data or desired format changes, when it might be more convenient to the end user to change the detail by some means outside the program.[1]
Hard coding is often required, but can also be considered an anti-pattern.[2] Programmers may not have a dynamic user interface solution for the end user worked out but must still deliver the feature or release the program. This is usually temporary but does resolve, in a short-term sense, the pressure to deliver the code. Later, soft coding is done to allow a user to pass on parameters that give the end user a way to modify the results or outcome.
The term "hard-coded" was initially used as an analogy to hardwiring circuits, and was meant to convey the inflexibility that results from its usage within software design and implementation. In the context of run-time extensible collaborative development environments such as MUDs, hard coding also refers to developing the core engine of the system responsible for low-level tasks and executing scripts, as opposed to soft coding which is developing the high-level scripts that get interpreted by the system at runtime, with values from external sources, such as text files, INI files, preprocessor macros, external constants, databases, command-line arguments, HTTP server responses, configuration files, and user input. In this case, the term is not pejorative and refers to general development, rather than specifically embedding output data.
Hard coding and backdoors
[edit]Hard coding credentials is a popular way of creating a backdoor. Hard coded credentials are usually not visible in configuration files or the output of account-enumeration commands and cannot be easily changed or bypassed by users. If discovered, a user might be able to disable such a backdoor by modifying and rebuilding the program from its source code (if source is publicly available), decompiling, or reverse-engineering software, directly editing the program's binary code, or instituting an integrity check (such as digital signatures, anti-tamper, and anti-cheat) to prevent the unexpected access, but such actions are often prohibited by an end-user license agreement.
Hard coding and DRM
[edit]As a digital rights management measure, software developers may hard code a unique serial number directly into a program. Or it is common to hard code a public key, creating the DRM for which it is infeasible to create a keygen.
On the opposite case, a software cracker may hard-code a valid serial number to the program or even prevent the executable from asking the user for it, allowing unauthorized copies to be redistributed without the need of entering a valid number, thus sharing the same key for every copy, if one has been hard-coded.
Fixed installation path
[edit]If a Windows program is programmed to assume it is always installed to C:\Program Files\Appname and someone tries to install it to a different drive for space or organizational reasons, it may fail to install or to run after installation. This problem might not be identified in the testing process, since the average user installs to the default drive and directory and testing might not include the option of changing the installation directory. However, it is advisable for programmers and developers not to fix the installation path of a program, since the default installation path depends on the operating system, OS version, and sysadmin decisions. For example, many installations of Microsoft Windows use drive C: as their primary hard disk, but this is not guaranteed.
There was a similar issue with microprocessors in early computers, which started execution at a fixed address in memory.
Startup disk
[edit]Some "copy-protected" programs look for a particular file on a floppy disk or flash drive on startup to verify that they are not unauthorized copies. If the computer is replaced by a newer machine, which doesn't have a floppy drive, the program that requires it now can't be run since the floppy disk can't be inserted.
This last example shows why hard coding may turn out to be impractical even when it seems at the time that it would work completely. In the 1980s and 1990s, the great majority of PCs were fitted with at least one floppy drive, but floppy drives later fell out of use. A program hard-coded in that manner 15 years ago could face problems if not updated.
Special folders
[edit]Some Windows operating systems have so-called Special Folders which organize files logically on the hard disk. There are problems that can arise involving hard coding:
Profile path
[edit]Some Windows programs hard code the profile path to developer-defined locations such as C:\Documents and Settings\Username. This is the path for the vast majority of Windows 2000 or above, but this would cause an error if the profile is stored on a network or otherwise relocated. The proper way to get it is to call the GetUserProfileDirectory function or to resolve the %userprofile% environment variable. Another assumption that developers often make is assuming that the profile is located on a local hard disk.
My Documents folder path
[edit]Some Windows programs hard code the path to My Documents as ProfilePath\My Documents. These programs would work on machines running the English version, but on localized versions of Windows this folder normally has a different name. For example, in Italian versions the My Documents folder is named Documenti. My Documents may also have been relocated using Folder Redirection in Group Policy in Windows 2000 or above. The proper way to get it is to call the SHGetFolderPath function.
Solution
[edit]An indirect reference, such as a variable inside the program called "FileName", could be expanded by accessing a "browse for file" dialogue window, and the program code would not have to be changed if the file moved.
Hard coding is especially problematic in preparing the software for translation to other languages.
In many cases, a single hard-coded value, such as an array size, may appear several times within the source code of a program. This would be a magic number. This may commonly cause a program bug if some of the appearances of the value are modified, but not all of them. Such a bug is hard to find and may remain in the program for a long time. A similar problem may occur if the same hard-coded value is used for more than one parameter value, e.g. an array of 6 elements and a minimum input string length of 6. A programmer may mistakenly change all instances of the value (often using an editor's search-and-replace facility) without checking the code to see how each instance is used. Both situations are avoided by defining constants, which associate names with the values, and using the names of the constants for each appearance within the code.
One important case of hard coding is when strings are placed directly into the file, which forces translators to edit the source code to translate a program. (There is a tool called gettext that permits strings to be left in files, but lets translators translate them without changing the source code; it effectively de-hard codes the strings.)
Hard coding in competitions
[edit]In computing competitions such as the International Olympiad in Informatics, contestants are required to write a program with specific input-output pattern according to the requirement of the questions.
In rare cases where the possible number of inputs is small enough, a contestant might consider using an approach that maps all possible inputs to their correct outputs. This program would be considered a hard-coded solution as opposed to an algorithmic one (even though the hard-coded program might be the output of an algorithmic program).
Soft coding
[edit]Soft coding is a computer coding term that refers to obtaining a value or function from some external resource, such as text files, INI files, preprocessor macros, external constants, configuration files, command-line arguments, databases, user input, HTTP server responses. It is the opposite of hard coding, which refers to coding values and functions in the source code.
Programming practice
[edit]Avoiding hard coding of commonly altered values is 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 numbers in their code to improve its readability and assist maintenance. These practices are generally not referred to as soft coding.
The term is generally used where soft coding 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. Soft coding, in this sense, was featured in an article on The Daily WTF.[3]
Potential problems
[edit]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 soft coded 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, 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.
To avoid soft coding, 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.
Achieving flexibility
[edit]Several legitimate design patterns exist for achieving the flexibility that soft coding attempts to provide. An application requiring more flexibility than is appropriate for a configuration file may benefit from the incorporation of a scripting language. In many cases, the appropriate design is a domain-specific language integrated into an established scripting language. Another approach is to move most of an application's functionality into a library, providing an API for writing-related applications quickly.
See also
[edit]References
[edit]- ^ Elfriede Dustin (2002). Effective Software Testing: 50 Specific Ways to Improve Your Testing. Addison-Wesley Professional. pp. 188–. ISBN 978-0-201-79429-8.
- ^ Tanya Janca (14 October 2020). Alice and Bob Learn Application Security. Wiley. pp. 15–. ISBN 978-1-119-68740-5.
- ^ Softcoding from The Daily WTF
Hard coding
View on GrokipediaFundamentals
Definition
Hard coding is the practice in software development of embedding fixed values, constants, or data directly into the source code of a program, rather than obtaining them from variables, parameters, configuration files, or external sources.[2] This approach integrates the data as literals within the code itself, making it an integral part of the program's logic and execution.[6] Common examples of hard-coded elements include literal strings such as file paths like"C:\Program Files", numeric identifiers like a user ID of 123, or fixed thresholds in algorithms, such as a cutoff value of 0.5 for decision-making processes.[7] Immutable mathematical constants, like the approximation of pi as 3.14159, are also frequently hard-coded to ensure precise and consistent usage without runtime computation.[6]
Developers may employ hard coding for its simplicity in small scripts or prototypes, where external configuration adds unnecessary overhead, or for performance optimization in critical sections, such as precomputing lookup tables to avoid repeated calculations at runtime.[6] It is particularly suitable for unchanging "real constants" that do not require flexibility, allowing for faster development and deployment in constrained environments.[6]
Comparison with Soft Coding
Soft coding refers to the practice of storing values and parameters outside the source code, using mechanisms such as configuration files, environment variables, databases, or external resources that can be modified at runtime or deployment without altering the program itself.[8] In contrast to hard coding, where values are statically embedded directly into the source code and become part of the compiled executable, soft coding enables dynamic adjustments that do not require recompilation or redeployment of the application. This fundamental difference means hard-coded elements are fixed at build time, while soft-coded ones allow for runtime flexibility, such as loading different configurations based on the environment. A primary trade-off involves performance versus adaptability: hard coding typically results in faster execution because it eliminates the need for file reads, parsing, or lookups at runtime, reducing overhead and improving efficiency in resource-constrained settings.[9] However, this comes at the cost of reduced portability, as changes necessitate code modifications and rebuilding, potentially complicating maintenance across diverse deployments. Soft coding, while introducing minor runtime overhead from configuration retrieval, greatly enhances adaptability, allowing updates without developer intervention and supporting easier scaling or customization.[8][6] Hard coding is often preferable in scenarios like embedded systems, where simplicity, low power consumption, and deterministic performance are critical, or for immutable constants such as mathematical formulas that rarely change.[9][6] Conversely, soft coding is favored in user-facing applications requiring localization, where strings and cultural settings are externalized to resource files for translation and adaptation without recompiling the core logic.[10]Applications and Examples
In Software Configuration and Paths
In software configuration, hard coding often manifests in the use of fixed paths for installation directories, such as embedding "C:\Windows" or "/usr/bin" directly into the code, which assumes a specific operating system layout and leads to portability issues when deploying across diverse environments like Windows and Linux.[11][12] For instance, a program compiled for Windows that relies on "C:\Program Files" will fail on Linux systems lacking that directory structure, necessitating recompilation or manual adjustments to adapt to paths like "/opt" or "/usr/local."[12] This practice limits cross-platform compatibility, as differing file system conventions—such as case sensitivity on Linux versus Windows—can cause runtime errors or failed installations.[11] Examples of hard-coded paths appear in bootloaders, where fixed references to startup disks or directories ensure initial system loading but reduce flexibility. In GRUB, the bootloader commonly used in Linux distributions, a hardcoded path like "EFI/BOOT/BOOTX64.EFI" is employed for UEFI systems to locate the executable on removable devices, allowing booting without prior configuration but tying the process to specific firmware expectations.[13] Similarly, references to special folders in user profiles, such as hard coding "C:\Documents and Settings\Username\Documents" from older versions like Windows XP, can break on upgraded systems where the path shifts to "C:\Users."[11] These fixed assumptions about profile directories, like embedding "C:\Documents and Settings" in legacy applications, prevent seamless migration to modern OS versions with restructured user folders.[14] In digital rights management (DRM) systems, hard coding plays a role by embedding fixed keys or license checks directly into the software to enforce content restrictions without relying on external servers. For example, some DRM implementations hard code cryptographic keys within the player application to validate licenses locally, simplifying deployment but binding the system to predefined validation logic.[15] This approach allows immediate enforcement of usage limits, such as playback counts or device bindings, by comparing runtime inputs against statically defined values in the code.[16] Historically, hard coding was prevalent in early software development due to the uniform and constrained computing environments of the mid-20th century, where hardware limitations made dynamic configurations unnecessary.[17] Developers often embedded constants and machine-specific addresses directly to optimize for compact, efficient code on machines like those running early Fortran in the 1950s, reflecting a "cowboy coding" style focused on functionality over adaptability.[18] With the rise of diverse platforms in the 1980s and beyond, such practices became outdated, supplanted by cross-platform tools that favor configurable paths for broader deployment.[17]In Programming Competitions
In programming competitions, hard coding is commonly employed in formats such as code golf and algorithmic contests like the ACM International Collegiate Programming Contest (ICPC) and Codeforces challenges, where brevity and computational efficiency are paramount. Participants often embed fixed values, including magic numbers (e.g., infinity as 1e9+7 for modular arithmetic) and sample test inputs, directly into the source code to streamline implementation and adhere to stringent character or time limits. This practice is particularly prevalent in code golf, a recreational variant where the objective is to produce the shortest possible program solving a given task, often leading to hardcoded outputs or data structures tailored to known test cases.[19][20] The advantages of hard coding in these contexts include reduced code length, which is critical for scoring in code golf, and minimized execution overhead under tight resource constraints, such as avoiding dynamic allocation or external input parsing. For example, contestants may hardcode fixed graph structures or precomputed arrays in graph theory problems on Codeforces, or embed sample data like coordinate arrays for local verification before submission. In ACM ICPC solutions, hard coding precomputed values—such as optimal configurations for combinatorial problems—or static elements like digit segment patterns in visualization tasks further exemplifies this, enabling concise implementations that pass automated judging efficiently. These techniques eliminate the need for runtime computations on invariant data, enhancing speed in time-bound contests.[21][22] Despite these benefits, hard coding limits reusability, as solutions tied to specific inputs or constants fail on varied or unseen test cases, a drawback mitigated in contests by the one-off nature of submissions and secret test suites that discourage full output hard coding. However, over-reliance on it, such as hardcoding exact test responses in code golf, can be viewed as exploiting known cases rather than demonstrating general algorithmic prowess, though it remains acceptable within rules emphasizing minimal code.[20] The evolution of hard coding in competitions traces to the 1970s emergence of automated evaluation systems alongside the ACM ICPC, the oldest major contest format originating in 1970 at Texas A&M University. Early implementations relied on predefined, hardcoded test datasets within judging infrastructure to verify solutions without external files or manual intervention, a standard that persists in modern online judges for reliable, scalable assessment across global participants. This approach, formalized in systems like those supporting ICPC and the International Olympiad in Informatics (IOI) since 1989, prioritized efficiency in evaluating algorithmic correctness over configurability.[23]Risks and Issues
Security Vulnerabilities
Hard coding sensitive information, such as passwords, API keys, or encryption keys, directly into source code creates significant security risks by exposing these credentials to unauthorized access. For example, in Python scripts, hardcoding API keys poses risks if the code is shared or stored insecurely, as the keys can be exposed through version control systems or code distribution.[24] When embedded in version control systems like Git repositories, these hardcoded secrets can be inadvertently leaked through public commits or stolen via repository breaches, allowing attackers to impersonate legitimate users and access protected resources. Similarly, once compiled into binaries, such credentials remain static and recoverable through reverse engineering, enabling exploitation without needing further authentication. For instance, hardcoding credentials for auto-login features can allow anyone with access to the server IP to fully utilize the system, making it suitable only for local or trusted intranet environments. The Open Web Application Security Project (OWASP) identifies the use of hard-coded passwords as a critical vulnerability, noting that it almost certainly grants malicious users access to affected accounts during the exposure period. The Common Weakness Enumeration (CWE) further classifies this as CWE-798: Use of Hard-coded Credentials, emphasizing that any product incorporating such practices risks full compromise of the embedded accounts.[25] Hard coding can also introduce backdoors, either intentionally for maintenance purposes or unintentionally through overlooked fixed access points, such as default admin passwords in networking devices. For instance, multiple router models from manufacturers like Cisco and ZTE have historically included hardcoded credentials that allow remote attackers to gain root access, bypassing standard authentication and enabling command execution or data exfiltration. In the case of Cisco's Emergency Responder software, static root account credentials have been documented as a persistent issue, exploitable via SSH connections to alter system configurations or install malware. In 2025, Cisco addressed a similar critical vulnerability (CVE-2025-20309) in Unified Communications Manager involving static root credentials exploitable via SSH.[26] These backdoors facilitate unauthorized entry, often remaining undetected until exploited in targeted attacks, as highlighted in analyses of firmware vulnerabilities. In digital rights management (DRM) systems, hard coding cryptographic keys or obfuscation checks exacerbates vulnerabilities by making them susceptible to reverse engineering and circumvention. Fixed keys embedded in software for content protection can be extracted using debugging tools, allowing attackers to create cracks that disable licensing enforcement and distribute pirated versions. This practice undermines the entire security model of DRM, as the static nature of the keys eliminates rotation or dynamic generation, rendering protections ineffective against determined adversaries. CWE-321: Use of Hard-coded Cryptographic Key describes this weakness, stating that it nearly guarantees malicious access, particularly in authentication or encryption processes reliant on such keys. Beyond individual components, hard coding contributes to broader threats like supply chain attacks, where shared codebases with embedded secrets propagate risks across ecosystems. Attackers compromising a vendor's repository can leverage hardcoded credentials to infiltrate downstream applications, amplifying the attack surface in interconnected environments. OWASP's Mobile Top 10 (M2: Inadequate Supply Chain Security) explicitly warns that hardcoded credentials in third-party libraries or SDKs enable such exploits, potentially granting access to mobile apps or backend services. Additionally, hardcoded paths in configurations, as seen in software setups, can indirectly serve as vectors by exposing sensitive file locations to traversal attacks if combined with other flaws.Maintenance and Flexibility Challenges
Hard coding introduces substantial maintenance challenges in software development, as modifications to embedded values often require extensive code alterations, recompilation, and redeployment, thereby elevating the potential for introducing errors during updates. For instance, in systems where values like configuration parameters are scattered across multiple modules, locating and updating them uniformly demands thorough code searches and verifications, prolonging development cycles and straining resources. According to the Consortium for IT Software Quality (CISQ), hard coding literals violates unit-level coding practices, diminishing code adaptability and amplifying overall complexity, which directly undermines maintainability as defined by ISO 25010 standards for modification efficiency.[27] Flexibility is further compromised by hard coding, particularly in areas requiring adaptation to diverse environments or requirements. In internationalization efforts, hardcoded strings must be identified and externalized to resource files to enable translation, a process that proves especially arduous in legacy applications where such strings are deeply embedded, complicating localization for global markets.[28] Similarly, hardcoded paths hinder cross-platform compatibility, as operating systems employ different conventions for file separators and structures (e.g., forward slashes on Unix-like systems versus backslashes on Windows), resulting in runtime failures when software is ported without adjustments.[29] For scalability, fixed hardcoded limits—such as predefined buffer sizes or connection thresholds—constrain system expansion, forcing code revisions to handle growing workloads or data volumes, which disrupts seamless growth in dynamic applications.[2] Although hard coding is sometimes perceived as offering performance advantages through direct value embedding without runtime resolution, this benefit is often marginal and overshadowed by drawbacks in debugging and testing. Substituting or mocking hardcoded elements for isolated testing becomes cumbersome, as it typically involves code edits rather than configuration tweaks, leading to brittle test suites and prolonged defect resolution.[30] In real-world scenarios, these practices accumulate technical debt in legacy systems, where hard coding exacerbates migration challenges during modernization efforts, inflating costs and delaying transitions to more adaptable architectures.[31]Mitigation Strategies
Best Practices for Avoidance
To detect hardcoded values in codebases, developers should incorporate regular code reviews into their workflows, where team members systematically examine source code for embedded literals, such as specific file paths or API endpoints, that could be externalized for flexibility.[32] Static analysis tools provide automated support for this process; for instance, SonarQube enforces rules like S1075, which flags hardcoded URIs in Java code by identifying string literals that resemble absolute paths or URLs without parameterization. Similarly, linters such as ESLint or custom regex-based scripts can scan for patterns like quoted absolute paths (e.g., "/usr/local/bin"), alerting developers to potential hardcoding before commits.[33] Prevention begins with establishing coding standards that require non-constant values—such as database connection strings or threshold limits—to be sourced from external configurations rather than embedded directly in code.[32] A key strategy is leveraging environment variables for deployment-specific settings, like server ports or API keys, which allows seamless adaptation across development, staging, and production environments without code modifications.[25] For interactive scripts, such as those in Python, prompting for sensitive information like API keys at runtime using the getpass module provides an additional method to avoid hardcoding, mitigating security risks associated with code sharing or insecure storage.[34] These practices align with broader secure coding guidelines, emphasizing parameterization to reduce maintenance overhead and security risks.[35] When hardcoding is identified in existing code, refactoring involves systematically extracting these values into dedicated structures, such as constants files for application-wide settings (e.g., moving a magic number like 42 to a named constant MAX_RETRIES) or configuration files for user-modifiable options.[36] For dynamic needs, values can be migrated to databases, enabling runtime updates via queries rather than rebuilds, which improves scalability in enterprise applications.[25] This approach, often termed "extract constant" in refactoring catalogs, preserves functionality while enhancing readability and adaptability.[37] At the organizational level, policies should mandate integration of secret-scanning tools into CI/CD pipelines to automatically detect and block hardcoded credentials during builds; for example, GitLab's built-in secret detection analyzes commits on default branches, using pattern matching to identify exposed tokens and prevent merges. Additionally, developer training programs must clarify acceptable uses of hardcoding, such as immutable mathematical constants like π (approximately 3.14159), while prohibiting it for environment-dependent or sensitive data, fostering a culture of configurable design.[32]Soft Coding Techniques
Soft coding techniques involve externalizing application parameters and behaviors from the source code to enable flexibility and maintainability. One primary method is the use of configuration files in formats such as JSON or YAML, which store settings like database connections or API endpoints separately from the codebase.[38] These files allow developers to modify application behavior without recompiling or redeploying code, supporting environment-specific adjustments during development, testing, and production phases.[39] Dependency injection (DI) serves as another key technique for injecting configurable values into components at runtime, promoting loose coupling and testability. In frameworks like ASP.NET Core, DI containers manage service lifetimes and resolve dependencies from external sources, such as configuration providers, ensuring that hardcoded values are replaced with dynamic ones.[40] Similarly, the Spring Framework uses DI to externalize object dependencies through constructor arguments or setter methods, often sourced from property files or databases.[41] For handling paths and environment-specific data, environment variables provide a secure and portable way to define values like file directories (e.g., using$HOME on Unix-like systems). These variables are accessible across operating systems and can be set at the system or process level, avoiding the need to embed absolute paths in code.[42] Localization frameworks, such as the i18n API in Ruby on Rails, enable dynamic string handling by storing translations in external files or dictionaries, allowing applications to adapt user-facing text based on locale without altering the core logic.[43]
Feature flags implement conditional logic by toggling functionality at runtime through external controls, often integrated with tools like LaunchDarkly or custom routers. This approach wraps code sections in if-statements evaluated against flag states, facilitating gradual rollouts or user segmentation.[44]
In advanced scenarios, microservices architectures externalize configurations using Kubernetes ConfigMaps for non-sensitive data and Secrets for credentials, enabling centralized management across distributed services.[45] Object-relational mapping (ORM) tools, such as those in AWS environments, further support database-driven values by abstracting SQL queries into object-oriented interactions, allowing dynamic data retrieval for application parameters.[46]
These techniques yield practical benefits, including support for A/B testing via feature flags, where variants are routed to user cohorts for performance comparison without code changes.[44] They also simplify updates by isolating configurations, aligning with the twelve-factor app methodology's emphasis on environment-based config to reduce deployment risks and enhance portability.[39]