You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Michael Bauroth (JIRA)" <ji...@apache.org> on 2006/04/03 00:01:43 UTC
[jira] Created: (DIRMINA-198) Naming conventions
Naming conventions
------------------
Key: DIRMINA-198
URL: http://issues.apache.org/jira/browse/DIRMINA-198
Project: Directory MINA
Type: Wish
Versions: 0.9.3
Reporter: Michael Bauroth
Priority: Trivial
It would be a great idea to define some naming conventions for the source code. Especially for new users, but also for all others it can be confusing to know, if a special variable in a longer method is static or global or anything else. Naming conventions can generate more readable code and a quicker programming progress.
In our company we use the following conventions:
static final variables: UPPER_CASE
static variables: sStatic (leading -s, next letter big)
global variables: mMember (leading -m, next letter big)
local (temporary) variables: tTemp (leading -t, next letter big)
parameters: pParam (leading -p, next letter big)
What do you think?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DIRMINA-198) Naming conventions
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-198?page=comments#action_12372864 ]
Emmanuel Lecharny commented on DIRMINA-198:
-------------------------------------------
As far as I know, there is a naming convention used for MINA and ADS project. Ok, it's not written somewhere on the site or in the wiki, too bad :)
So here are the common rules :
- CAPITAL_LETTERS for constants
- java naming convention for names. No m_, no prefix. They are useless. If the method is long, and if you feel that you may confuse two variables, then split your method in two. Hungarian notation was used in a context where you didn't had any graphic IDE...
- a space after (, and before ) like :
if ( value == 1 )
- { and } are on the same column :
if ( value == 1 )
{
// code
}
- No tabs, 4 spaces.
- in general, use spaces around signs like =.
If you browse the code base, you will see that they are some places where those rules are violated, but generally speaking, these are the rule we are now trying to follow.
Of course, they are just like any other rules : if you break them, they won't yell :)
> Naming conventions
> ------------------
>
> Key: DIRMINA-198
> URL: http://issues.apache.org/jira/browse/DIRMINA-198
> Project: Directory MINA
> Type: Wish
> Versions: 0.9.3
> Reporter: Michael Bauroth
> Priority: Trivial
>
> It would be a great idea to define some naming conventions for the source code. Especially for new users, but also for all others it can be confusing to know, if a special variable in a longer method is static or global or anything else. Naming conventions can generate more readable code and a quicker programming progress.
> In our company we use the following conventions:
> static final variables: UPPER_CASE
> static variables: sStatic (leading -s, next letter big)
> global variables: mMember (leading -m, next letter big)
> local (temporary) variables: tTemp (leading -t, next letter big)
> parameters: pParam (leading -p, next letter big)
> What do you think?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (DIRMINA-198) Naming conventions
Posted by "Trustin Lee (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-198?page=all ]
Trustin Lee resolved DIRMINA-198.
---------------------------------
Resolution: Won't Fix
Assignee: Trustin Lee
I agree with Peter and we're already doing the same for static final members. Most modern IDEs are intelligent enough to syntax-highlight the code to distinguish static fields and non-static fields.
> Naming conventions
> ------------------
>
> Key: DIRMINA-198
> URL: http://issues.apache.org/jira/browse/DIRMINA-198
> Project: Directory MINA
> Issue Type: Wish
> Affects Versions: 0.9.3
> Reporter: Michael Bauroth
> Assigned To: Trustin Lee
> Priority: Trivial
>
> It would be a great idea to define some naming conventions for the source code. Especially for new users, but also for all others it can be confusing to know, if a special variable in a longer method is static or global or anything else. Naming conventions can generate more readable code and a quicker programming progress.
> In our company we use the following conventions:
> static final variables: UPPER_CASE
> static variables: sStatic (leading -s, next letter big)
> global variables: mMember (leading -m, next letter big)
> local (temporary) variables: tTemp (leading -t, next letter big)
> parameters: pParam (leading -p, next letter big)
> What do you think?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DIRMINA-198) Naming conventions
Posted by "peter royal (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-198?page=comments#action_12372863 ]
peter royal commented on DIRMINA-198:
-------------------------------------
The only one I agree on is with static final variables. The rest is just noise (imo)
> Naming conventions
> ------------------
>
> Key: DIRMINA-198
> URL: http://issues.apache.org/jira/browse/DIRMINA-198
> Project: Directory MINA
> Type: Wish
> Versions: 0.9.3
> Reporter: Michael Bauroth
> Priority: Trivial
>
> It would be a great idea to define some naming conventions for the source code. Especially for new users, but also for all others it can be confusing to know, if a special variable in a longer method is static or global or anything else. Naming conventions can generate more readable code and a quicker programming progress.
> In our company we use the following conventions:
> static final variables: UPPER_CASE
> static variables: sStatic (leading -s, next letter big)
> global variables: mMember (leading -m, next letter big)
> local (temporary) variables: tTemp (leading -t, next letter big)
> parameters: pParam (leading -p, next letter big)
> What do you think?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DIRMINA-198) Naming conventions
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-198?page=comments#action_12372891 ]
Emmanuel Lecharny commented on DIRMINA-198:
-------------------------------------------
I know tat using prefix seems a good idea. I must admit that I have used them a long time ago. I was an adept of hungarian notation a while back (it was in the late 80). I used a lot of m_ for member variables because I hated to use the this.var = var idiom (m_var = var looks like a btter idea).
But right now, I do think that it's not a good idea. What is important is not the code you read on article, papers or blog, it's the code you are debugging or writing. This is real code, with real issues, and you need real tools to deal with it. Everything else is pure abstraction...
IMHO, and trust me, I've changed my mind more than once !!!
> Naming conventions
> ------------------
>
> Key: DIRMINA-198
> URL: http://issues.apache.org/jira/browse/DIRMINA-198
> Project: Directory MINA
> Type: Wish
> Versions: 0.9.3
> Reporter: Michael Bauroth
> Priority: Trivial
>
> It would be a great idea to define some naming conventions for the source code. Especially for new users, but also for all others it can be confusing to know, if a special variable in a longer method is static or global or anything else. Naming conventions can generate more readable code and a quicker programming progress.
> In our company we use the following conventions:
> static final variables: UPPER_CASE
> static variables: sStatic (leading -s, next letter big)
> global variables: mMember (leading -m, next letter big)
> local (temporary) variables: tTemp (leading -t, next letter big)
> parameters: pParam (leading -p, next letter big)
> What do you think?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DIRMINA-198) Naming conventions
Posted by "Michael Bauroth (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-198?page=comments#action_12372889 ]
Michael Bauroth commented on DIRMINA-198:
-----------------------------------------
I agree with all above regarding the coding conventions. The readability of the code is even better then most other code I've seen before :) Some of the rules were new for me, but I've tried to use them in my last sample too.
On the other hand I think, the use of prefixes in variables (without underscore) can help to improve the readability too. We can't assume that everyone uses a graphic IDE or syntax highlighting. Another case is the use of code dump in articles, mails ... there we haven't syntax highlighting too. When we use only small code samples out of the box without figuring out, of which type some variables are (or giving them some prefixes), the reader don't know what they are.
But ok, it was only a wish :)
> Naming conventions
> ------------------
>
> Key: DIRMINA-198
> URL: http://issues.apache.org/jira/browse/DIRMINA-198
> Project: Directory MINA
> Type: Wish
> Versions: 0.9.3
> Reporter: Michael Bauroth
> Priority: Trivial
>
> It would be a great idea to define some naming conventions for the source code. Especially for new users, but also for all others it can be confusing to know, if a special variable in a longer method is static or global or anything else. Naming conventions can generate more readable code and a quicker programming progress.
> In our company we use the following conventions:
> static final variables: UPPER_CASE
> static variables: sStatic (leading -s, next letter big)
> global variables: mMember (leading -m, next letter big)
> local (temporary) variables: tTemp (leading -t, next letter big)
> parameters: pParam (leading -p, next letter big)
> What do you think?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira