EAWFStandard

← Return to Main_Page

---

Purpose

The EAWF Software Development Standard defines the minimum quality, documentation, installation, and support requirements for all software released by EAWF.

The objective is simple:

• Deliver software that is useful, professional, predictable, easy to install, easy to maintain, and enjoyable to use.

• Every EAWF project should provide a consistent user interface and experience regardless of language, operating system, or application.

EAWF Standards

• General
  • Projects
  • Scripts
  • Credits and Attribution
  • Documentation Headers and Footers
  • Business Plan Templates

Programs/Scripts

BTC

• BTC
  • Startup
  • Management
  • BTC Program

Connect

• Scripts
  • Scripts
  • Scripts
  • Scripts
  • Scripts
  • Scripts
  • Scripts
  • Scripts
  • Scripts
  • Scripts

Core Philosophy

The EAWF Software Development Standard is based on the following principles:

• Follow established Linux conventions whenever practical.
• Keep programs simple.
• One tool should perform one primary task well.
• Do not expose implementation details to the user.
• Auto-detect sensible defaults whenever possible.
• Allow users to customize behavior without modifying program code.
• Never overwrite user configuration without permission.
• Documentation is part of the product.
• Installation and removal should be safe and straightforward.

---

Quality Standard

A version 1.0 release must satisfy the following requirements.

Functional:

• Stable operation
• No known functional defects
• Predictable behavior
• Clear error handling
• Professional command output

---

User Experience

• Clean command syntax
• Consistent help screens
• Quiet operation
• Friendly messages
• No unnecessary technical output
• Consistent formatting throughout the application

---

Installation

Every project should include:

• `.install.sh`
• `.uninstall.sh`
• README.md
• CHANGELOG.md
• LICENSE
• Man page
• Example configuration files

The installer should:

• Install safely
• Preserve existing user configuration
• Create missing configuration files from examples
• Verify prerequisites
• Report missing dependencies clearly

The uninstaller should remove the application while preserving user data unless explicitly requested otherwise.

Linux Standards

• Programs should follow normal Linux conventions.

• Programs usually run from /usr/local/bin

• User Configuration: ~/.config/<project>/ e.g., ~/.config/connect/

• Documentation Location: /usr/local/share/doc/<project>/

• Manual Pages: /usr/local/share/man/man1/ e.g., /usr/local/share/<project>/examples/

• Logs: ~/.local/state/<project>/
  • Applications should create log directories only when logging is actually needed.

• Cache:
  • Applications should **not** create cache directories unless there is a legitimate performance benefit.

• Avoid creating unnecessary files or directories "just in case."

• Configuration Philosophy: Separate configuration into logical responsibilities.

• Project Configuration: Contains definitions describing the project itself.

Example:
* Servers
* Hosts
* Network links
* Project mappings
* Deployment targets
Example:
connect.conf

• User Settings: Contains user preferences.

Example:

• Preferred editor
• Preferred file manager
• Color preferences
• Future display options

Example:

``` settings.conf ```

---

1. Auto First

Every application should attempt to make intelligent default decisions.

Users should only need to customize behavior if they want something different.

Examples:

• Respect `$EDITOR`
• Auto-detect running file manager
• Automatically disable color when output is redirected
• Honor existing SSH configuration

---

1. Customization

Power users should always be able to override automatic behavior.

Customization should be achieved through configuration files rather than modifying application code.

---

1. Documentation

Every project should provide documentation at three levels.

1. 1. README

Project overview

• Purpose
• Installation
• Quick start
• Examples
• Philosophy

---

1. 1. Man Page

Reference documentation

• Synopsis
• Commands
• Files
• Environment
• Examples
• Exit codes

---

1. 1. Website

The EAWF website serves as the living documentation.

It may contain:

• Tutorials
• Screenshots
• Frequently Asked Questions
• Configuration examples
• Troubleshooting
• Release notes
• Known issues
• Future enhancements

---

1. Error Handling

Applications should report problems in language users understand.

Avoid exposing raw command output unless it is genuinely useful.

The user should see results rather than internal implementation details.

---

1. Design Philosophy

Good software should:

• Respect the operating system.
• Respect the user's configuration.
• Respect the user's time.
• Stay out of the way.
• Be reliable enough that users stop thinking about it.

---

1. EAWF Motto

• • Simple. Predictable. Configurable.**

Applications should be approachable for beginners while remaining powerful enough for experienced users.

---

1. Release Criteria

A project may be declared Version 1.0 when it:

• Meets all functional requirements.
• Meets the EAWF Software Development Standard.
• Includes complete documentation.
• Includes installation and removal procedures.
• Has been tested through normal daily use.
• Is considered production ready.

Version 1.0 represents the beginning of long-term support, not the end of development.