Home

Map

OS++ Down Load

Doco_A

Youtube

Chat

News

Shop

//#! Declaration: http://osplusplus.org/2022standard/Shop

TLDR; The top line, is a standard declaration using the format (CODE.org/STANDARD/GRADE). You are using this declaration to notify future readers that the following code is written in OS++, with the 2022 syntax standard. The grade is used in a company. It may be based on the industry standard and tweaked or be a whole new thing. It is accompanied by a rem mark that tells you where the shop grade can be found. eg.

//#! Declaration: http://osplusplus.org/2022standard/Shop
//
// Shop standard - http://YOUR_INTRANET.com/shop_standard_20220726

The declaration just happens to be an HTML link, which has more information.

For a list of standard declarations and a better explanation. Please visit http://osplusplus.org/2022standard/professional
To see the Language documentation for this language. Please visit http://osplusplus.org/2022doco

The Shop grade

TLDR; This is a standard that is used in a company. It may be based on the industry standard and tweeked or be a whole new thing.

//#! Declaration: http://osplusplus.org/2022standard/Shop
//
// Shop standard - http://YOUR_INTRANET.com/shop_standard_20220726

This is the standard you want to see when joining a new company. It will explain the patterns that are used and how to integrate with your new team at the new shop or company. This should allow you to better fit in and draw as little attention to yourself as possible, while becoming a productive member.

General use

When you declare this, please add a //rem, that advises readers of the standard and where it’s definition can be found. eg.

// shop standard - http://YOUR_INTRANET.com/shop_standard_20220726

It will be tempting to add this to the versioning repository code base, but I advise adding it to your local internal intranet along with a _YYYY_MM_DD ending. That way, as the standards change you will have a good idea what was going on with a simple click of the link. Old standards, on old code bases as just as important as the latest, as old code is brought up to date. This reduces “friction” as the standard is only a click away and does not have to be dug out of the version control system. This makes it much more likely that the standard will actually be followed.

How this should be used

1. Standards change. New patterns emerge. The world keeps turning. You will probably need to evolve the code standard. No one wants refactoring as a cost item. Where is the business benefit? And if there is none, how can it be justified? So it needs to be done “under the cover” outside of the businesses direct control, it’s an evolutionary process. An old block of code needs a new feature. You see the old standard declaration in the old code, you will instantly know the work load you are being faced with to refactor it. Real business benefits with a low, pay as you go cost.

2. A 20 year old something joins the company and wants to reinvent the wheel. They start adding a library/pattern that has not been agreed upon in development. The latest and totally flawed, hot new technology. Slowly they infect the code base with their latest pattern which is totally incompatible with the well reasoned and thought out code base. As lead developer you send them a “please explain”. Did you not read the company standard? It’s declared on every piece of code. If you want to work on a new standard, there is a working meeting at 4pm on Friday. Bring pizza.

Site summary (added to bottom of every page)