AES Code Conventions and Style Guide - 1610oct24java/AssociateEvaluationSystem GitHub Wiki

Code Conventions and Style Guide

Refer to this guide for team code style and naming conventions for project 3.
This document is subject to change and must be referred to often.

Peace

Table of Contents
I. Git
II. Oracle
III. Java
IV. Web
V. Markdown

Git

Naming Conventions

Team Prefixes:

  • Core Interface: core
  • Assessment: asmt
  • Test Bank: bank

Branch Names:

  • Begin with team name
  • Each subsequent branch name is separated by a hyphen
  • Staging branch is appended with dev
  • All feature branches extend dev, but do not contain the dev keyword
  • Feature branches use camelCase for feature names
  • If multiple people are working on the same feature, make a new branch with name appended

Sample branch structure:

core
core-dev
core-sendEmail
core-sendEmail-pski
core-sendEmail-willie

Beans are in beans

Oracle PL/SQL

Code Conventions

  • Avoid using PL/SQL keywords (see resources for complete list)
  • Individual words within identifiers shall be seperated by an underscore
  • All table names will be prepended with: aes_
  • All constraints shall contain a logical prefix, such as:
    • Primary Keys: pk_primay_key
    • Foreign Keys: fk_tablename_colname
    • Checks : ck_constraint_name
  • Declare foreign key constraints outside of create table statements
  • UUID for primary keys? (see resources)
  • Date/Time Format:
    • uhhh???

Style

  • Indent using 2 spaces
  • Add line breaks and indentation for readability
    • When selecting/inserting multiple columns, put each column on a different line, ending line with a comma
    • See resources below for additional info on how and when to use line breaks and indentation
    • As a rule of thumb, mimic the style used on Tech On The Net
  • For creation/alteration statements, put semicolons on a seperate line to assist with editing
  • All table constraints (with the exception of foreign key constraints) shall be placed after the declaration of all column names
  • comments? do we care about style here?

Table creation and general styling sample

/* sample format for create table statments */

CREATE TABLE reimbursement_reqs (
  
  req_id NUMBER,
  date_submitted DATE DEFAULT(SYSDATE),
  req_status VARCHAR2(255) DEFAULT('pending'),
  
  -- foreign keys
  emp_id NUMBER NOT NULL,     -- references: employees
  event_id NUMBER NOT NULL,   -- references: trms_events
  
  CONSTRAINT pk_reimbursement_reqs
    PRIMARY KEY (req_id),
  
  CONSTRAINT ck_valid_status
    CHECK (
      req_status IN (
        'pending',
        'awaiting info',
        'supervisor approved',
        'dept head approved',
        'benco approved',
        'accepted',
        'declined',
        'cancelled'
      )
    )
);

Adding foreign key constraints sample

/* sample format for adding foreign key constraints */

--add foreign key constraint:
  --reimbursements(emp_id) -> employees(emp_id)
ALTER TABLE reimbursements
ADD CONSTRAINT fk_reimbursements_emp_id
  FOREIGN KEY (emp_id)
  REFERENCES employees(emp_id)
  ON DELETE CASCADE
;

Resources

Java

Code Conventions

Base package name: com.revature.aes

Style

camelCase and PascalCase for stuff and things none_of_this_awesomeness()

Web Stuff

this section should not be decided by Matt Pierzynski

Markdown

Use markdown for all things readme. It looks pretty, and isnt too difficult to pick up.

Resources