Skip to content

Coding_Standards

Jason Pell edited this page Jun 21, 2013 · 1 revision

Table of Contents

Introduction

Most of these standard practices are followed in the code, however some deviations are to be expected. If you stick to these standards, OpenDb will be far more maintainable.

Some of OpenDb core code is spaghetti code, and this is something that needs to be resolved sooner rather than later. A lot of the completely new functionality in OpenDb is class based which makes it much easier to avoid spaghetti.

Coding standards

  • Use 4-space TAB indenting. (Use tab character and set your editor to 4 spaces)
  • Always start your brace off on the next line (C style, not C++)
  • Always use braces around while,for,foreach,etc constructs.
  • Always use braces around if, where you are including anything but the one line statement. (For example comments)
  • Comment for function should proceed the function, similiar to javadoc comment /** */.
  • Do not use # comments in php, always use C++ style // or /* */
  • Use 'echo' but don't use 'print'

Database Abstraction

Make sure you use the database abstraction layer functions instead of the mysql_ ones

  • db_error()
  • db_errno()
  • db_query()
  • db_affected_rows()
  • db_insert_id()
  • db_free_result($result)
  • db_fetch_assoc($result)
  • db_fetch_row($result)
  • db_field_name($result, $field_offset)
  • db_num_rows($result)
  • db_num_fields($result)

Naming Standards

Database Functions

Prefixes

  • fetch_
  • update_
  • delete_
  • insert_
  • validate_


The name of the table should come next. For tables with an s_ prefix, you do not have to include that.



If the fetch for instance, returns most of the table, then you are set.



If you only return a couple of columns, then add them to the function name:

fetch_user_id_and_fullname


If the function joins two tables, include the other tables in the function name as well. Use common sense to not overdo this:

fetch_user_item_


Finally the suffix of functions is required. This is only of importance for fetch_/get_ functions:

  • _r -> For a record (array)
  • _rs -> A resultset
  • _cnt -> A int, which is the result of a select count(...) operation.



Non-Database functions



For non-database functions, do not use fetch_, but get_ for operations where you are computing a value.




Variables



Where a variable is being returned from a fetch, especially a _r, use the same format as for the function name, just remove the fetch_ prefix.



For all others use your discretion. But I recommend, that if you are getting results from a _rs suffix function. Each time to use db_fetch_assoc($result), assign it to a _r of the same prefix (minus fetch_ as the function name)

The wiki migration is a work in progress. I am aware that some images don't currently work.

Clone this wiki locally