[Tinyos-beta-commits] CVS: tinyos-1.x/beta/teps/txt tep3.txt, NONE,
1.1
Ion Yannopoulos
ion- at users.sourceforge.net
Mon Jan 24 01:19:24 PST 2005
- Previous message: [Tinyos-beta-commits]
CVS: tinyos-1.x/beta/teps/txt tep105.txt, 1.1, 1.2
- Next message: [Tinyos-beta-commits]
CVS: tinyos-1.x/beta/teps/html tep3.html, NONE,
1.1 tep1.html, 1.4, 1.5 tep101.html, 1.1, 1.2 tep106.html, 1.1, 1.2
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Update of /cvsroot/tinyos/tinyos-1.x/beta/teps/txt
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv24630/txt
Added Files:
tep3.txt
Log Message:
Coding Convention TEP.
--- NEW FILE: tep3.txt ---
================================
Coding Standard
================================
:TEP: 3
:Group: TinyOS 2.0 Working Group
:Type: Best Current Practice
:Status: Draft
:TinyOS-Version: 2.x
:Author: Ion Yannopoulos
:Draft-Created: 31-Dec-2004
:Draft-Version: $Revision: 1.1 $
:Draft-Modified: $Date: 2005/01/24 09:19:22 $
:Draft-Discuss: TinyOS-2.0 Working Group list <tinyos-2.0wg at mail.millenium.berkeley.edu>
.. Note::
This document specifies a Best Current Practices for the
TinyOS Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited. This memo
is in full compliance with [TEP_1]_.
Abstract
========================================================================
This memo proposes a coding convention for use in TinyOS source code.
It identifies a number of issues, particularly of naming, and proposes
recommendations for how to manage them.
1. Introduction
========================================================================
[-Still to be written-]
.. Note::
[Notes in square brackets are to grab your attention. They will not be in
the final document.]
.. Note::
[These are **recommendations**. Even when it says "requirement" that only
means I feel especially strongly about such cases. I have tried to keep
these to a minimum. And while it would be best if code in the core follows
these rules, contributed code can arguably do as it likes (until the day it
decides to be in the core.)
By all means if you have an objection to them shoot them down.
Keep in mind that in matters of aesthetics we may not have agreement
and a convention is usually desirable nonetheless.]
2. Namespaces
========================================================================
A brief discussion of namespaces in TinyOS and how to implement them is
relevant. Programmers should easily be able to distinguish between the
following:
- Which package (loosely defined) the component or name belongs to.
- Whether a name belongs to the HPL, HAL, or HIL [TEP_2]_.
- Distinguishing between names which are meant to be publically
accessible outside their current implementation, and names
which are meant to be implementation only.
- [It's not clear to me how many components `are` actually private...]
- In NesC, distinguishing between interfaces, configurations, and modules.
- In C, C++, and Java, distinguishing between types, functions, and variables.
- Whether code is in NesC, C, C++ or in Java, all of which have different
requirements, and in the case of C and NesC should avoid colliding with
each other.
Each of the above can potentially lead to a fair amount of confusion if
it is not easy to do. They can also lead to name collisions which, if unnoticed,
can be rather difficult to resolve.
There are several ways to protect names:
.. _namespaces_builtin:
- Use a builtin language facility.
- C++, Java (and other languages such as Perl and Python) all have
support for dividing up the namespace.
- C does not. There is not a great deal of C in TinyOS, but it is
especially important to be careful with it.
- NesC provides some namespacing for names declared inside interfaces
and components. Namespace collisions are still possible between
components.
- A package system has been proposed for NesC, which is similar to
Java's. It has not been discussed in great detail.
.. _namespaces_prefix:
- Use prefixes or suffixes.
- This is done by attaching a common string <package> to all names
declared in 'package', e.g. `<package>Type`, or `<package>_function`.
Note that `underscores are contentious`__.
__ issue_using_underscores_
- This method requires that programmers are consistent in their
use of prefixes.
.. _namespaces_directory:
- Use directory structure.
- Use subdirectories to break up categories of names. This is certainly
useful in the case of platform breakdown.
- This method requires agreement on the directory structure, and
configuration of include paths.
3. General Conventions
========================================================================
Minimum for check-ins
---------------------
**Requirements**:
- All code accepted must meet the testing standard.
- All code accepted must have NesDoc documentation for all functions,
and at least a minimal README. The README may refer to some
external documentation (e.g. a web page).
Author, Title of project, Short description, Contact info (optional)
.. Note::
[Perhaps this belongs in another document?]
Choosing names
--------------
Recommendations:
- Prefer a long clear name to short one which makes assumptions.
Rationale:
- People read code far more often than they write it, even in a research
environment. Make names as clear as possible is important.
- Most modern IDEs (including `emacs` and `vim`, do name-completion (tab-completion).
You don't have to type everything.
Namespaces
----------
Recommendations:
- All code written in languages other than nesC SHOULD be namespaced in
whatever fashion that language allows.
Rationale:
- Avoiding name collisions is generally helpful.
- Knowing what namespace a name belongs in aids readers of the code
in finding definitions. It should not require use of `grep` or
constant digging to find where names are defined.
Notes:
- See each language below for particular namespacing recommendations.
- With the exception of C++, tools exist to enforce such stylistic
constraints, usually by reformatting code before it is submitted.
Directory and File Names
------------------------
Issues:
- Case sensitivity is a nuisance in OS portability, since it some OS'es (Windows)
are not case sensitive, and others (Unix derivatives) are. Mixing case is likely
fine as long the same name is not present with different case. There are several options
for dealing with this:
- Require a particular case, mixed or lower, for all file and directory names.
- Require a particular case for file names and another for directory names. This is
similar to how Java does it.
- Allow any case, as long as each package is consistent.
Recommendations:
- Any case SHOULD be allowed, as long as each package is consistent.
- Filenames for classes and components SHOULD match the class or component name.
- Directories that contain a logical namespace SHOULD have the same name as
that namespace (though the case of that namespace is dependent on the language
feature, not the directory name.
- Consider that directories can `help with namespaces`__.
__ namespaces_directory_
Rationale:
- Requiring fixed case for all filenames or directories is certainly an option.
It works for Java. I'm not sure this covers all the cases well (e.g. application
directories).
Case of names
-------------
Recommendations:
- Names SHOULD strictly follow mixed case.
- Acronyms that are part of names SHOULD be in mixed-case NOT all-caps.
Rationale:
- A number of other standards recommend this.
- Mixed case is generally believed to make the name clearer to human eyes.
- Tools that might need to do detect the form of a name are simpler.
- There is an ambiguity between names and suffixes: e.g is "EEPROM"
an interface, or the module for "EEPRO"? It may seem obvious
but it can be confusing if you don't know what an eeprom is.
Examples:
- Use `Uart` not `UART`.
- Use `Msp430` not `MSP430`.
- Use `AdcControl` not `ADCControl`.
- Use `Eeprom` not `EEPROM`.
Abbreviations & Acronyms
------------------------
Recommendations:
- Abbreviations SHOULD be restricted to generally accepted abbreviations.
- Acronyms SHOULD be restricted to generally accepted acronyms.
- Such terms SHOULD be documented somewhere.
Rationale:
- Technical abbreviations are part of the jargon of the field and
you can generally expect that someone in the field will know them
or at least be learning them. Other types of abbreviations are
unnecessarily unclear.
- Documenting which terms are accepted is likely to be of some help
to people new to the field.
Examples:
- `Uart`, `Adc`, `Leds` are accepted outside of TinyOS usage.
- `Comm`, and `Msg` are fairly standard within TinyOS usage.
- `Cnt` for "count", `Cntl` for "control", `Cfg` for configuration are
only alright if we use them universally instead of their longer forms.
- `Pot` for "Potentiometer" is especially lossy.
- Anyone who hasn't worked on `WMEWMAMultiHopRouter` have any idea what
"WMEWMA" means?
Documentation
-------------
Recommendations:
- All code submitted must have inline documentation comments, to
allow for automatic generation of documentation.
- All documentation SHOULD follow a documentation recommendation,
which needs to be written, for languages other than Java.
This file can be based off of the [JavaDoc_Documentation_Convention]_,
and the [JavaDoc_Documentation_Extended_Convention]_.
Rationale:
- Undocumented code is a nuisance. Automatically generated
documentation is easy to enforce (and even set dependencies
for in the build system.)
Note:
- See each language below for a recommended documentation tool.
4. NesC conventions
========================================================================
General Naming
--------------
Issues:
- We want to:
- Distinguish the names of interfaces and components.
- Distinguish the names of configurations and modules.
- Distinguish types, functions, and variables.
- Current use of suffixes is somewhat inconsistent, and some components have
suffixes while others have none.
- We currently have two different interpretations of the "C" and "M" suffixes:
- The current coding convention puts "C" at the end of public component name
whether it is a configuration or a module. It only uses "M" if a configuration
and a module both exist.
- `Pros`:
- The public name is always the same, so changing the implementation from
a configuration to a module or vice versa is transparent. (This means
never wiring to an 'M').
- `Cons`:
- This is not actually easy to explain, as evidenced by the fact that
people don't seem to be following the equivalent rule in the
[TinyOS_1.x_Coding_Convention]_ with much consistency.
- A number of people put "C" at the end of all configurations and "M" at the end of all modules.
- `Pros`:
- This is very simple to explain. People ranging from TinyOS experts
to less experience users seem to find this intuitive.
- The implementation of a component is obvious on sight.
- `Cons`:
- You always need to write a configuration, even when you
only one for the module. Otherwise you end up wiring to the
modules.
Filenames
---------
Recommendations:
- Filenames SHOULD be the name of the type contained within, including the prefix,
with a ".nc" extension.
Rationale:
- It should be easy to tell what is defined in a given file by the name.
Packages
--------
Recommendations:
- All names in a 'package' (essentially a library), SHOULD have the package name as
a `prefix`__. This name SHOULD end with an underscore.
- All platform specific names SHOULD be prefixed with the platform's name as a package.
There may be subpackages with
- All files in a package SHOULD go in the same root directory. There may or may not
be further subdirectories, and these need not affect the name.
__ namespaces_prefix_
- The "system" package (the one in the `system/` and `interfaces/` directories among
others has no prefix.
- The package 'Tos' and all of it's subpackages are reserved to the system for `use
with C code`__.
__ c_packages_
Rationale:
- This avoids name collisions between components at compile time.
- It makes the name's point of definition obvious.
- The system package is special. As it will be used everywhere it seems useful to
keep those names short.
- `Underscores are contentious`__.
__ issue_using_underscores_
Examples:
- `Msp430_*`, `Msp430Cc2420_*`, `Mica2_*`, `Deluge_*`, `Mate_*`
Interfaces
----------
Requirements:
- Interfaces MUST not have any special suffixes.
Recommendations:
- Interfaces SHOULD be nouns or verbs. Nouns are encouraged.
- Interfaces SHOULD follow the general conventions regarding case
and naming.
- Interfaces SHOULD try particularly hard to have clear and well-defined names.
Longer is better.
Rationale:
- Interfaces should not be confused with components.
- The `as` keyword may be used to shorten names for actual use, but they need
to be clear to the reader.
Examples:
- `Adc`, `Clock`, `Timer` (in 'tos/lib' in the system package)
- `Deluge_PageTransfer`, `Deluge_Metadata` (in the `deluge` package)
- `Mate_Buffer`, `Mate_Engine`, `Mate_Queue` (in the `mate` package)
- `Msp430_Adc`, `Msp430_Init`, `Msp430_Clock` (in the `platform/msp430` package)
Components
----------
Requirements:
- All configuration names MUST end in "C". All modules names MUST end in "M".
The absence of an interface with the same name does not affect this restriction.
Recommendations:
- Wiring in configurations SHOULD be done only other configurations, or the
module with the same name as the configuration.
- If a component is the basic implementation of an interface it MAY have
the same name as the interface, plus its extension.
Rationale:
- If wiring is only done to other configurations, it reduces the scope of
changes necessary changes need to be made to a module just to the configuration.
Essentially it shields other components from implementation changes.
- Components must have suffixes so as not to be confused with interfaces.
- In the suffix matter, the simplicity of explanation appears to be the strongest
argument.
Examples:
- `AdcC`, `AdcM`, `TimerM` (in 'tos/lib' in the system package)
- `Deluge_MetadataC`, `Deluge_MetadataM` (in the `deluge` package)
- `Mate_BufferM`, `Mate_EngineC`, `Mate_EngineM` (in the `mate` package)
- `Msp430_AdcM`, `Msp430_TimerC` (in the `platform/msp430` package)
Types
-----
Recommendations:
- Types SHOULD be in mixed case, capital letter first.
- All types (`struct` s, `enum` s, `typedef` s) declared in a NesC `module` SHOULD NOT
need any prefixes.
- All types declared in a C file and referenced in Nesc via `includes` should
use the `C rules for types`__.
__
Rationale:
- NesC automatically protects names declared in modules with the module name.
Examples:
- `struct BufferEntry` (in .nc file)
- `struct Pong_Msg` (in .c file)
Compiler-generated types:
-------------------------
Recommendations:
- All types generated by the compiler (with the prefix "__nesc_") SHOULD be
hidden behind 'Tos' prefixed names. You should never see "__nesc" in
NesC code.
Rationale:
- TinyOS may be dependent on a particular NesC implementation, but it should
not export that dependency unnecessarily.
Examples:
- `typedef __nesc_atomic_t TosAtomic`;
- OR (if we treat these as special types) `typedef __nesc_atomic_t tos_atomic_t`.
Commands, Events, and Tasks
---------------------------
Recommendations:
- Commands, events, and tasks SHOULD be in mixed case, lower case letter first.
- Commands, events, and tasks SHOULD NOT need any prefixes.
- Commands and events SHOULD be verbs.
- It is recommended that commands be in the present tense (to indicate an action
that is being taken), and events be in the past tenst (to indicate an action
that has just occured.)
- A command and an event that represent the two phases of a split phase operation
SHOULD be matched in name, with the event suffixing "Done" (or the equivalent)
to the command.
- Tasks SHOULD be nouns describing some process. (This can be done by taking
a verb and suffixing it with 'Task'.)
Functions and Macros
--------------------
Requirements:
- Macros MUST NOT be declared in .nc files.
Rationale:
- Even if this is currently legal there is no guarantee it will be in the future.
Recommendations:
- Functions SHOULD be in mixed case, lower case letter first.
- Functions declared in a NesC `module` SHOULD NOT need any prefixes.
- Functions SHOULD be verbs.
- See `C functions and macros`__ for information on macros.
__ _c_functions_and_macros
Rationale:
- Names follow a Java-like convention.
Variables and Constants
-----------------------
Recommendations:
- Variables SHOULD be in mixed case, lower case letter first.
- Variables and constants declared in a NesC `module` SHOULD NOT need any prefixes.
- Variables and constants SHOULD be nouns.
- Constants SHOULD be in all-caps, with words separated by underscores.
- Module level global variables SHOULD be prefixed with "m\_".
- Like all names variables and constants should be descriptive, but local variables
MAY be short. In particular loop variables MAY be a single letter as per common
convention.
Rationale:
- Names follow a Java-like convention.
- Module level variables should be easily distinguishable from local variables.
This isn't nearly the problem in NesC that it is in C, as all global variables
are namespaced by their module at link time, but it's still useful to be able to
see instantly that a variable is defined at the module level.
Hardware Abstraction Architecture
---------------------------------
Issues:
- The distinction between the HPL, HAL, and HIL is subtle enough that
we want to make it as easy as possible to identify which one an
interface is part of.
- Is it reasonable for `-I</path/to/names>` automatically look in
`-I</path/to/names>/h[ap]l?`
Recommendations:
- All HPL, HAL, and HIL [TEP_2]_ interfaces are platform related
so they should be put in the platform directory. Within the
platform directory:
- HPL interfaces and components should go in a `hpl/` subdirectory.
- HAL interfaces and components should go in a `hal/` subdirectory.
- HIL interfaces and components should be in the base directory.
Rationale:
- We seek to avoid having every name that's in a HPL/HAL be
prefixed with HPL or HAL, as that makes names longer and
more cluttered. On the other hand we want to know easily
which names are part of a platform's HAL or HPL. Subdirectories
make this straightforward.
- HIL is meant to be platform independent and this seems a good choice
for a default (i.e. in the base directory).
- It's not clear that `this is sufficient`__. Prefixes may be necessary.
__ issue_with_hpl_names_
Examples:
- Msp430Radio, Msp430Adc, hpl/Msp430Adc, hal/Msp430Adc
Applications
------------
Recommendations:
- TinyOS applications should be the name of the toplevel component without
any extension.
- Applications should be sorted into subdirectories depending on their
category, one of:
- `demo/`
- `test/` (for tests of software)
- `verify/` (for tests of hardware)
Rationale:
- A directory breakdown for kinds of applications keeps related applications
together and prevent the `apps/` tree from getting cluttered.
Directory structure
-------------------
Recommendations:
- A convention for the directory structure SHOULD be made explicit.
Rationale:
- The meanings of the various directories under `tos/` should be made
explicit, or at least more than they are now. In particular the
distinction between `types/`, `system/`, and `libs/` (and the breakdown
within `libs/`) should be made clear.
5. C conventions
========================================================================
.. _c_packages:
General Naming
--------------
Issues:
- C code has two major conventions:
- Mixed Case: ATypeName, aFunctionName, aGlobalVariableName
- All lower case, with suffixes: a_type_name_t, a_function_name, a_variable_name_g
- It really doesn't matter which convention we pick, as long as we
actually _pick_ one. People tend to have strong preferences.
All that really matters is that no one have to guess what the
intent ia.
Recommendations:
- Types, functions, and variables SHOULD be distinguished from one another.
- Global variables should be distinguished from local variables.
Files
-----
Requirements:
- Header files MUST have a ".h" extension.
- Source files MUST have a ".c" extension.
Rationale:
- Every C compiler in the world expects this.
Recommendations:
- C code associated with a type should be in a header/source file with that type
as a name.
- C code associated with a NesC component should be in a header/source file with
that component's name, but with C extensions.
Examples:
- PongMsg.h, PongMsg.c
Packages
--------
Recommendations:
- The package 'Tos' is reserved to the system. All shared C code SHOULD (MUST) be
prefixed with `Tos*_`, `tos*_`, or `TOS*_`, depending on the case of the rest of the name.
- Individual packages within the system SHOULD have subpackages. The underscore
goes after the full package name.
- A special provision needs to be made for symbols which are defined by a platform,
for the system at large. Those symbols are simply in the top-level 'Tos' package.
Rationale:
- People coding NesC should not need to worry about collisions with C names.
- There's no other way to do namespaces in C.
- Symbols that are in the toplevel package but in package subdirectories are thus
clearly marked as platform independent.
Examples:
- `Tos_*`, `TOS_*`
- `TosMsp430_*`, `TOSMSP430_*`
- `TosMsp430Cc2400_*`, `TOSMSP430CC2400_*`
Types
-----
Issues:
- `result_t` and `error_t` do not follow convention. If they did they would be
`Tos_Result` and `Tos_Error`. Perhaps they should be considered special types.
This will work providing we are clear on which types are special.
- This issue does *not* hold for `int16_t` and other `<stdint.h>` types as standard
C defines them, not TinyOS.
Recommendations:
- Types (structs, unions, enums, typedefs) SHOULD be in mixed case,
first letter capitalized.
- Types should be packaged prefixed.
Rationale:
- This is a fairly standard convention for types, and matches the one we use
for NesC (except for the '`Tos_`' package prefix).
Examples:
- `Tos_Result`, `Tos_Error`
- `Tos_Msg` (or `Tos_Message`?)
- `struct TosMsp430_TimerAControl`
- `enum TosMsp430_TimerCode`
.. _c_functions_and_macros:
Functions and Macros
--------------------
Requirements:
- Macros MUST be prefixed.
Rationale:
- Prefix your macros. The preprocessor has no concept of namespaces and short
names are a recipe for pain.
Recommendations:
- Functions SHOULD be in mixed case, first letter lowercase.
- Functions SHOULD be package prefixed.
- If functions are considered to be part of a type, they should be prefixed with the
type as well, but the type goes after the underscore.
- Functions SHOULD be verbs.
- Macros SHOULD be in all-caps, with words separated by underscores.
- If AT ALL POSSIBLE inline functions SHOULD be used for short functions.
Function-like macros SHOULD be avoided.
- Rationale:
- Names follow a Java-like convention.
- Compiler support for inline functions is better than for macros. For example
a debugger can identify the call points for an inline function but it cannot
for a macro.
- Examples:
-
Variables and Constants
-----------------------
Recommendations:
- Variables SHOULD be in mixed case, lower case letter first.
- Global variables and constants SHOULD be packaged prefixed.
- Variables and constants SHOULD be nouns.
- Constants SHOULD be in all-caps, with words separated by underscores.
- Like all names variables and constants should be descriptive, but local variables
MAY be short. In particular loop variables MAY be a single letter as per common
convention.
- If AT ALL POSSIBLE, `enum`s and `const int`s SHOULD be used for constants.
Constants with `#define` SHOULD be avoided.
Rationale:
- Names follow a Java-like convention.
- Compiler support for `enum` and `const` is significantly more useful that `#define`
constants. For example a debugger can see the symbol names for the former but has
no idea about the latter.
Documentation
-------------
- Recommendations:
- Documentation should be generated with [Doxygen]_.
6. Java conventions
========================================================================
Recommendations:
- All Java code should follow the standard [Java_coding_convention]_.
- All Java code belongs in a subpackage of `net.tinyos`.
Rationale:
- Most of the rest of the world writes Java this way.
Staying compatible makes our Java code readily accessible.
Documentation
-------------
Recommendations:
- Documentaton should be generated with [JavaDoc]_.
7. C++ conventions
========================================================================
Packages
--------
- Recommendations:
- All C++ code SHOULD be in the `tinyos` namespace.
Files
-----
- Recommendations:
- All files should be named after their primary class.
- All header files SHOULD be suffixed with `'.hh'`.
- All source files SHOULD be suffixed with `'.cc'`.
- All inline source files SHOULD be suffixed with `'.ii'`.
- Examples:
- `EventQueue.hh`, `EventQueue.cc`
- `RadioModel.hh`, `RadioModel.ii`, `RadioModel.cc`
Types, Functions, Variables
---------------------------
- Recommendations:
- The Java coding convention SHOULD be mapped to C++ inasmuch as possible.
- Rationale:
- This is preferrable to writing a small book, which is what C++ coding
conventions turn into.
Documentation
-------------
- Recommendations:
- Documentation should be generated with [Doxygen]_.
Open Issues
========================================================================
.. _issue_using_underscores:
.. Note::
There is some disagreement about having underscores after package names.
- Pros:
- Long package names can blend in with types:
- MyPackageSubPlatform_MyComponent or MyPackageSubPlatformMyComponent?
- Msp430Cc2420_Radio or Msp430Cc2420Radio?
- Cons:
- There was some dislike expressed at typing underscores. This in and of
itself doesn't seem enough reason not to use them, but if it's a
universal annoyance it's worth getting rid of them.
However if we really don't want them, we shouldn't have `result_t` or `error_t`
either, and CONSTANTS_WITH_UNDERSCORES should disappear also.
.. _issue_with_hpl_names:
.. Note::
It's possible that if HPL/HAL names are not `prefixed`__ there will be
collisions between the HPL, HAL, and HIL versions of a name. If that's
so prefixes are necessary:
__ namespaces_prefix_
Examples:
- HplMsp430Adc instead of hpl/Msp430Adc
- HplAtmel128Adc instead of hpl/Atmel128Adc
In that case are directories still useful?
.. _issue_component_overrides:
.. Note::
This document does not adequately address the use of overrides of
component names.
.. _issue_private_components:
.. Note::
This document does not address the issue of components private to
an implementation.
8. Author's Address
========================================================================
| Ion Yannopoulos
| 410 Soda Hall
| UC Berkeley
| Berkeley, CA 94720
9. Citations
========================================================================
.. [TEP_1] TEP 1 <http://www.tinyos.net/working_groups/tinyos-2.0wg/teps/tep-1.html>
.. [TEP_2] TEP 2 <http://www.tinyos.net/working_groups/tinyos-2.0wg/teps/tep-2.html>
.. [Doxygen] Doxygen <http://www.doxygen.org>
.. [Java_Coding_Convention] Java Coding Convention <http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html>
.. [JavaDoc] javadoc <http://java.sun.com/j2se/javadoc>
.. [JavaDoc_Documentation_Convention] JavaDoc Documentation Convention <http://java.sun.com/j2se/javadoc/writingdoccomments/index.html>
.. [JavaDoc_Documentation_Extended_Convention] JavaDoc Documentation - Extended Convention <http://geosoft.no/development/javastyle.html>
.. [TinyOS_1.x_Coding_Convention] TinyOS 1.x Coding Convention <http://www.tinyos.net/tinyos-1.x/doc/tutorial/naming.html>
- Previous message: [Tinyos-beta-commits]
CVS: tinyos-1.x/beta/teps/txt tep105.txt, 1.1, 1.2
- Next message: [Tinyos-beta-commits]
CVS: tinyos-1.x/beta/teps/html tep3.html, NONE,
1.1 tep1.html, 1.4, 1.5 tep101.html, 1.1, 1.2 tep106.html, 1.1, 1.2
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
More information about the Tinyos-beta-commits
mailing list