Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
Kea
Kea
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 427
    • Issues 427
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 69
    • Merge Requests 69
  • Operations
    • Operations
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
  • ISC Open Source Projects
  • KeaKea
  • Wiki
    • Processes
  • coding guidelines

coding guidelines · Changes

Page history
Update coding guidelines authored Nov 23, 2020 by Tomek Mrugalski's avatar Tomek Mrugalski
Hide whitespace changes
Inline Side-by-side
Showing with 8 additions and 1 deletion
+8 -1
  • Processes/coding-guidelines.md Processes/coding-guidelines.md +8 -1
  • No files found.
Processes/coding-guidelines.md
View page @ c5e5c60c
......@@ -634,7 +634,7 @@ should be resolved using executables they are loaded into.
# User Interface (UI) Guidelines
BIND 10 is a server process, so does not have much that would be considered a user interface. This section discusses what we do have.
Kea is a server process, so does not have much that would be considered a user interface. This section discusses what we do have. See [Stork coding guidelines](https://gitlab.isc.org/isc-projects/stork/-/wikis/Processes/coding-guidelines) for UI guidelines for Stork.
## IP address and port formatting
......@@ -652,6 +652,13 @@ For IPv6 addresses, this looks like this:
If you import code from another project, try to continue the style of the imported project if changes need to be made. This is for two reasons, one is to make merging future versions easier. The other is the encouragement of submitting changes upstream.
# Deprecating options
Sometimes we need to introduce changes that are not backward compatible. If possible we try to support the old way while making the new way possible. When introducing new alternative ("new way") that eventually going to replace an existing option ("old way"), there should be at least one stable series which supports both old and new way. If old syntax is used, a warning should be printed urging people to update their syntax.
For example:
The old `reservation-mode` parameter has been replaced with `reservations-global`, `reservations-in-subnet` and `reservations-out-of-pool` in 1.9.2. A warning should be printed if `reservation-mode` is used. Such a warning should be coded as soon as realistically possible to give people as much advance warning as possible. As such, this will be implemented in 1.9.2, so early adopters will see it right way. It will be included in 2.0, where users preferring stable will see it. The old way can be removed somewhere in 2.1.x, so 2.2 will not accept it anymore. This way people who use only stable version will have time to migrate. They'll see the warning when moving from 1.8 to 2.0 and will have time until 2.2.
# Guidelines Adopted by Other Projects
Other projects have their own coding guidelines. Here're some
......
Clone repository
  • Home
  • Hooks available
  • Processes
    • coding guidelines
    • gitlab howto
    • release process
    • smaller edits on gitlab
  • Release Notes
  • Simplified Flow Diagram
  • community developed tools
  • designs
    • Backend Assisted Lease Selection design
    • Basic LeaseQuery Design
    • Design documents
    • HA connection with MT support
    • HA split brain issues
    • Run external script hook
View All Pages