Class naming convention

many a times i face difficulty with the Action/Class naming convention.
Say, today ..i wrote a class.....tomorrow i have to rename the name of the class so that it becomes a more meaningful name and becomes unique and understandable with the newcomer classes.
...just to do this, i had to change the name of the class very frequently.
Though i follow few conventions like :
1) First letter of the class is Captial letter.
2) use names which is relevant with the classs's functionality.
but still i fall in problem....
say, i want to populate a DataBase with my class.....whats the name i should keep ? tommorrow i am going to write another class which also populate the database . what do i do ?
i first rename the old class with some meaningful name and then i write the new class with some other meaningful name.....but this kills time.....demands lots of changes....and so on...
you know, i get trouble when my number of classes increases.
do u feel the same ?
what are the rules (NOT JAVA RULES but meaningful rules) i should remember to keep a class name ?

You can name a class based on what it supposed to
do...
while naming it follow conventions like the ones
which are mentioned in the code
conventions/guidelines of your project.
You will not be writing the same functionality in two
different classes... would you??
In case you may need to refractor(rename the class
name) you may use java editor with refractoring
capability to do it..
With most of the java editors, you get this
functionality.. e.g. doing a Alt+Shift+R would
refractor your selected method, class, field etc...
This applies to Eclipse
>
Hope that helps..
Vaibhav

Similar Messages

Compiled Class naming conventions?

I have come across this situation on several large projects I have been involved in (several thousand class files) and can not explain it.
Given a class with subclasses within like so
class rob {
class steve {
} // end class steve
} // end class rob
the expected compiled files are
rob.class
rob$steve.class
I have come across the situation where a class with sub classes actually names itself
rob$1.class
rob$steve.class
Can anyone explain this? (typically the class extends some abstract class). Is there a way to avoid this?

"steve" is an inner class of "rob", so it compiles to "rob$steve.class". And "rob$1.class" will be the compiled form of an anonymous inner class. That's the naming convention.
What do you mean by "avoid this"? What's your problem with it?

ADF class naming convention when content compression is turned on

Hi all,
I am a user experience designer and I am now working on a project that requires to use numbers of custom styleClasses, and in order to style the objects to meet the requirements, I referenced the custom styleCalsses in the skin file and everything works fine just as I expected.
But when my colleagues turned on the content compression to boost the performance of the application, all the class names including my custom styleClasses are converted into things like x25, x26, x1nh, x1ni...
So I manually duplicated all the skin css attributes and changed all the class names to the newly generated ones, although this method seems to be working, I am still not sure if this is the safe way and best practice for future development ,because there is no clue to prove that these new class names are static and unique, which means some day my css may lose effect entirely.
Does anyone have the same experience when using content compression and what's your recommendation when dealing with content compression?
Thanks in advance,
Joey

Thank you so much for your reply during the holiday season.
I guess both scenarios exist, I can see some of styles did get picked up, like those on the buttons. But some styles that contain customized styleClass names seemed to have lost track of.
see example bellow:
.........working styles when compression is on.......
.loginButton {
    -moz-box-shadow:inset 0px 1px 0px 0px #7a8eb9!important;
    -webkit-box-shadow:inset 0px 1px 0px 0px #7a8eb9!important;
    box-shadow:inset 0px 1px 0px 0px #7a8eb9!important;
    background:-webkit-gradient(linear, left top, left bottom, color-stop(0.05, #637aad), color-stop(1, #5972a7));
    background:-moz-linear-gradient(top, #637aad 5%, #5972a7 100%);
    background:-webkit-linear-gradient(top, #637aad 5%, #5972a7 100%);
    background:-o-linear-gradient(top, #637aad 5%, #5972a7 100%);
    background:-ms-linear-gradient(top, #637aad 5%, #5972a7 100%);
    background:linear-gradient(to bottom, #637aad 5%, #5972a7 100%);
    filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#637aad', endColorstr='#5972a7',GradientType=0);
    background-color:#637aad!important;
    border:1px solid #314179;
    border-radius: 1px;
    display:inline-block;
    color:#ffffff!important;
    font-weight:bold;
    padding: 1px 15px;
    text-decoration:none;
    text-shadow:0px 1px 0px #39690d;
    position: relative;
    top: -2px;
    left: -6px;
    height: 22px;
......loose track when compression is on......
.LoginUsername .AFPanelFormLayoutContentCell .af_inputText_content {
    height: 18px;
    margin: 2px 3px 0 8px;
    border-radius: 1px;
    box-shadow: 0 0 5px #DDDDDD inset;

Naming convention for packages and classes

Hi all,
Is there any naming conventions for packages and classes which uses a design pattern ?. If yes what are the conventions used for business delegate,session facade, service locator,DAO and any other patterns.
rgds
Anto Paul

Hi,
that is a good question and one we have considered also. We dont yet cover the naming conventions for classes based on patterns but maybe will in the future. Currently, in the blueprints apps we tend to do some things like naminga class
-AccountDAO etc for DAOs
-For servicelocator we have a class called ServiceLocator viewable at https://adventurebuilder.dev.java.net/source/browse/adventurebuilder/ws/components/servicelocator/src/java/com/sun/j2ee/blueprints/servicelocator/web/ServiceLocator.java?rev=1.4&content-type=text/vnd.viewcvs-markup
-for session facade, its a bit trickier since the name is so long and we cant add "SessionFacade" to the end of each facade class. I think in general we put "Facade" in the name, usually near the end
-For Business Delegat, again it seems too long to add to each class name. So in the past we have added
a "BD" to the names of the delegates. Some examples are at http://java.sun.com/blueprints/patterns/BusinessDelegate.html
-For transfer objects we usually add a TO to the end of the name. Some examples at http://java.sun.com/blueprints/patterns/TransferObject.html
Seems like something we could get a bit more consistent about.
hope that helps,
Sean

What's the naming convention for Helper Class?

Hi Experts,
What's the naming convention for helper class?
cl_util? or cl_heper?
Thanks in advance!

Hi.,
Normally in JAVA the naming convention for Helper Class is <EventID>Util.java. The Naming convention for helper class must start with EventID.
here Event ID is the event Name , Util.java is the helper class for java.
I believe the same will be followed in ABAP OO too..
here the helper class is cl_uitl.,
so <EventID><ABAP hepler class> is the naming convention.
wait for experts reply..,
hope this helps u.,
Thanks & Regards,
Kiran

ArrayOfClass naming convention in webservice

When I generate array of any class through autotype, the name of the serialiser, deserialise and type name in wsdl generated as ArrayOfClassName.
But according to WSI basic profile 1.0 naming convention (R2112), bea should not use ArrayOfClassName.
Here is the sample code snippet..
<autotype javatypes="[LPackage.Interest;"
targetNamespace="${namespace}"
packageName="XX.YY" encoding="literal" destDir="${build}/NonBuiltType" />
Can someone please tell me if autotype has any flag or facility to change the naming convention?
Thanks in advance. A reply would be very much appreciated.
cheers
Biswa

Hi Deepti,
we have the following naming convention:
Aggregation Level similar to Cube:
e.g. Cube = ZPP_RC01 --> PP for Production Planning; RC for Real-time Cube and 01 just a sequential number
than the Aggregation Level will become ZPP_AL01 --> AL for Aggregation Level
Filter:
starting with AL name and just a sequential number: e.g. ZPP_AL01_F1
Planning function:
e.g. ZPF_01 ... PF for Planning Function and sequential number
Planning Sequence
e.g. ZPS_01 ... PS for Planning Sequence and sequential number
Best greetings,
Peggy

Naming convention in template css file

Is there a specific reason for having the theme "name" hardcoded in many css definitions ?
For example consider the css for the rows in a report:
In the css files for each theme it is defined in a different way:
Theme1: td.t1data
Theme2: td.t2data
Theme3: td.t3data
...Overriding these values and manipulating the styles using Javascript gets a bit cumbersome if it should work across themes.
Are there any naming conflicts or is it just for historic reasons that don't apply anymore in the 2.0 release?
In other words, would it be safe to use just td.data in new templates or will I run into problems doing this?
Thanks,
~Dietmar.

Hi Carl,
thanks for the clarification. I had figured that you had a good reason to do so.
It's a tradeoff, either approach has pros and cons.
Most likely we will stick with that type of naming convention, but we'll look into it again.I would like to throw in an idea. You can add multiple css classes to an html tag, e.g.
<td class="t12data data">The css for the class data would be empty.
This way we could have both, different class names for different themes, but also having the elements "tagged" the same way so that the javascript should work.
Haven't thought it out, it just came to my mind. You might consider it.
And yes using td.data should be just fineI guess I will go down that route.
I will create only a single theme and then use multiple css style sheets to modify the look and feel.
This way I can switch the theme on the fly by switching style sheets only.
Javascript modifications will work since the css class names are the same.
All customized region templates will only have to be created once (and not for all themes).
Thanks and a Happy New Year,
~Dietmar.

Hard to find ripping naming conventions

?In Mediasource Player 3.3, I had a really hard time finding the naming convention settingsdialog. It is in the media folder format settings option. I ended up with a bunch of ripped tracksthat had the track name twice and couldn't find the option. Hopefully this thread will help someoneso they don't have to struggle as much as I did. In the Settings pop-up the PC Music Library tab,and the Properties button under the first item which is the name of your current PC Music libraryname. I had failed to change the last box on the bottom right from track name to none. Ta paj692

I guess the argument against your argument is that your code should be as self-documenting as possible. In your code, I'll see "Event". Great. java.awt.Event? No (annoyance #1 already). Your base Event? I wouldn't know, need to check the imports first. Aaahh, scrolled up and saw: your special implementation Event it was. Although, I will not see that if I'm not familiar with your package structure and you're doing package imports.
Create packages for functional groups, otherwise you'll end up with loads of unnecessary public declarations because your helper classes are splattered all over the place and can't just rely on in-package visibility.
And by the way, using polymorphism properly like you don't seem to do, you'll screw yourself, because you'll in future have to do things like:
Event ev = new com.mystuff.special.implementation.Event();Because you can't import both the interface/superclass and the implementation. Congratulations.

Best practices in Internal table naming convention GT , GS , LT , LS ??

Hi Gurus,
 Are GT_ , GS_ , LT_ , LS_ --- the Best practices in Internal table naming convention ????
 I have seen this naming convetions adhered in standard programs .
 What each one of the below signify
 GT_ , GS_ , LT_ , LS_ ???????
Regards
Jaman
Message was edited by:
 ABAP Techie

Hello
I use the following naming conventions:
- G = global variable
- L = local variable
- T = internal table
- S = structure
- D = field
That's how the combinations look like:
- GT_ITAB = global itab
- GS_STRUC = global structure
- GD_FIELD = global field
- LT_ITAB = local itab
- LS_STRUC = local structure
- LD_FIELD = local field
Function module parameters have to stick to the following rules:
- I = importing
- E = exporting
- [C = changing -> never used]
- IT_ITAB = imported table type (itab)
- IS_STRUC = imported structure
- ID_FIELD = imported field
- ET_ITAB = exported table type (itab)
- ES_STRUC = exported structure
- ED_FIELD = exported field
Depending on their semantics TABLES parameters look like:
- IT_ITAB = imported data
- ET_ITAB = exported data
- XT_ITAB = changing data (import & export)
Here are the conventions for FORM routine parameters:
- UT_ITAB = using itab (data are usually treated like constants; no changes will be transfer - although possible - to the calling program)
- CT_ITAB = changing itab (if it is semantically an exporting itab then one of the very
first statements in the routine is: REFRESH ct_itab. )
- US_STRUCT
- UD_FIELD
- CS_STRUCT
- CS_FIELD
Conventions for class/interface parameters:
- IT_ITAB = importing table type
- IS_STRUC = importing structure
- ID_FIELD = importing field
- ET_ITAB = exporting table type
- ES_STRUC = exporting structure
- ED_FIELD = exporting field
- RT_ITAB = returning table type
- RS_STRUC = returning structure
- RD_FIELD = returning field
Conventions for class/interface attributes:
- MT_ITAB = table type
- MS_STRUC = structure
- MD_FIELD = field
- MC_CONST = constant
Question: Are there any advantages of such elaborated naming conventions?
My answer to this question is: Yes, definitively.
I believe that the advantage of semantically differentiating TABLES parameters of function modules is quite obvious:
CALL FUNCTION 'Z_BAD_NAMING'
 TABLES
 itab1 = ...
 itab2 = ...
 itab3 = ... .
CALL FUNCTION 'Z_GOOD_NAMING'
 TABLES
 it_itab1 = ...
 et_itab2 = ...
 xt_itab3 = ... .
I also believe that my naming conventions clearly enhance readability and maintainability of my programs.
Regards
Uwe

ABAP Naming Conventions

Hi All,
I'm looking for a document describing ALL basic ABAP Naming Conventions. For example, how to name data types such as tables, structures, predefined ABAP types, and so on. Furthermore, it would be desirable to know how the declaration changes in different contexts - report, form, function module, class, and so on.
Thank you.

Hi,
as I am working as a consultant for lots of companies in last 10 years, I know that there is no such document. Each company has it's own naming conventions and programming guides. The only thing that is common for all companies is: All customer defined stuff starts with a Z or a Y and in case the company registered it's own name space it starts with /<name space/. May be, somebody can send you these guides coming from whatever company.
regards
Siggi

Private vs. protected, naming conventions etc.

I've been grappling with a couple of frustrations with Forte, and I'm
interested in feedback from others on this list regarding approaches
they may have adopted to address these.
One is that in the Forte workshops there is no way to view only the
public methods and attributes of a class (we're still using V2 here; I'm
assuming that V3 has not changed this). While referring to appropriate
technical documentation for a class is obviously important, I still find
myself opening up classes in the workshops to inspect the methods and
attributes available. (What I really want to see is an integrated class
browser. I sure hope Forte is working on something like this, or will
open up their development environment to support third-party extensions.
But that's an aside.)
A convention I just recently adopted in my work is to name private
methods and attributes with a beginning underscore ("_"). That way the
private elements are sorted to the top of the list and can be easily
differentiated from public elements. I'm curious, though, whether others
have adopted similar or different approaches.
I've also felt a bit frustrated over the lack of support for protected
attributes/methods for TOOL classes. This strikes me as a rather
bothersome shortcoming. The only approach I can think of is to make such
elements public, but adopt the same or similar naming conventions as a
strong hint to developers to avoid using these in clients of these
classes. Again, I'd be very interested in hearing how others have dealt
with this issue.
Thanks.
Michael Brennan
Programmer/Analyst
Amgen Inc.

I sent this once before, but the list seemed to be having trouble late last
week. If you get two copies of it... my apologies.
OK, I couldn't resist joining the fray...
At 10:56 AM 11/6/97 -0800, Michael Brennan wrote:
>
A convention I just recently adopted in my work is to name private
methods and attributes with a beginning underscore ("_"). That way the
private elements are sorted to the top of the list and can be easily
differentiated from public elements. I'm curious, though, whether others
have adopted similar or different approaches.You might even designate a single character before the underscore to denote
that, just in case some environment (CORBA) doesn't like the "_". You could
make it something like "Q" or "Z" or something that wouldn't normally be
used alone at the start of a name.
>
I've also felt a bit frustrated over the lack of support for protected
attributes/methods for TOOL classes. This strikes me as a rather
bothersome shortcoming. The only approach I can think of is to make such
elements public, but adopt the same or similar naming conventions as a
strong hint to developers to avoid using these in clients of these
classes. I share your desire for protected methods, but I have to disagree about
protected attributes. Philosophically speaking, protected and public
attributes are EVIL!! (I say "philosophically speaking" because, in the
Forte environment, there are some valid reasons for using them based upon
the visibility constraints of the language. In other languages, C++ and
Java, for example, it's not even philosophically speaking - they're just
evil!!)
One of the principal reasons for adopting the object paradigm is to
tightly control the impact of change - to provide good boundaries of
encapsulation that change does not ripple beyond. If you think about it,
one of the measures of the success of a superclass is the number of
subclasses that it has (especially for a good dabstract interface). This
says you have very nicely captured the semantics of the application domain
in the interface of the superclass. So, let's imagine a superclass with
protected attributes that are used by each of its 100 subclasses (probably
more than you would have, but I'm illustrating my point - incidentally, I'm
not talking about a hierarchy 100 deep; I'm talking about 100 subclasses
that are all direct decendants of the superclass). Now you go and change
one of the attributes. You must go look at all 100 subclasses to determine
the impact of change. This is exactly the kind of thing the object paradigm
was designed to eliminate.
Protected methods, on the other hand, would be nice.
And At 12:06 PM 11/6/97 -0800, Mark S. Potts wrote:
>
Forte inherits in a strange way when attributes are private. A
superclass attribute that is made private is not accessible from any of
its subclasses - this means that many of what you would consider private
attributes in fact have to be public. Well, the definition of private means "not visible outside of the class
where it is defined". I find it useful to think of the level of visibility
the same as secrets. There are things that are not really secrets at all -
it's ok if anyone knows them ("My name is Stephen"). These are public.
Then, there are things that it's ok if my family knows, but I don't want
the world to know - familial secrets, if you will ("I belch at the dinner
table when I'm at home"). These are visible to descendant classes and we
call them protected. Finally, there are things we don't want anyone else
to know, no matter who they are ("I poisoned my mother-in-law"). These are
private. We don't want anyone outside of ourselves to know these things.
These are the classic definitions of public, protected and private (perhaps
classic only because C++ defined them that way and everyone else just
copied what it meant).
Private attributes are not meant to be inherited by their subclasses.
That's why they're private. And, yes, I would argue that that is completely
correct. What you want, if you want them to be visible to subclasses, is
"protected". Now, Forte doesn't support protected, but that's a different
arguement - perhaps even an enhancement request.
We also should not confuse what we need to do in a language/environment
with what good OO principles are. For example, good OO design principles
state that you do not have public or protected attributes. Period! You
access them via accessors and mutators defined on the appropriate class.
Now, in some environments, this will not give you the performance you need,
so you open things up a bit. But, you shouldn't convince yourself that
doing this is the ideal design, just that it was necessary for performance.
The real problem here is that the performance of accessor and mutator
functions is not fast enough. That's why we open it up. Not because it is
good design. The proper way to fix the problem is to make accessors and
mutators fast enough so that they can be used (C++, for example, does this
with "inline" - not that C++ is my favorite language, it's not. But they
have fixed this one area nicely.)
Some would argue that this is correct and that inheritance does break thepure rules
of encapsulation I don't think inheritance, properly handled (and Forte does properly
handle it) breaks any rules of encapsulation. I would argure that the way
they treat private attributes is quite correct.
- but these people dont build applications!Hmmm... let's see... started building OO applications in 1985 (and building
them ever since) in complex application domains like CAD/CAM/CAE, Air
Traffic Control, Graphics/Imaging, Telecommunications, e-commerce,
entertainment,... ...wrote (and teach) the Forte OO Analysis and Design
course.
I guess you're right. I don't build applications. I build robust,
maintainable, extendable applications. ( ;-) ...nudge, nudge!)
Stephen

Naming Conventions - programmer refuses to stick to them... what to do?

A fellow programmer on my team, though good, often refuses to abide by naming conventions, or seem even to be aware that many have existed and use that knowledge accordingly.
Today, for example, he created a class (not an interface) called Createable. I pointed out to him that convention over the years has been that classes ending in '-able' were usually interfaces, or might be suspected to BE interfaces by other programmers looking at his code.
He said he didn't care.
I then later noticed he had an interface defined in another package called 'Createable'. So he had made two classes of the same name in different packages, one an interface and one not.
Our boss doesn't seem to mind this kind of thing (he just wants us to get the work done and isn't interested in quibbling over things like naming convensions). Perhaps I'm a bit stern about these kinds of things, but it really gets my goat when this happens.
What's your opinion, Java Community?
- Tim
Edited by: user2052552 on Feb 3, 2011 12:41 PM

user2052552 wrote:
A fellow programmer on my team, though good, often refuses to abide by naming conventions, or seem even to be aware that many have existed and use that knowledge accordingly.
Many conventions? As in your team doesn't have a convention but you want them to follow one which is unspecified?
Today, for example, he created a class (not an interface) called Createable. I pointed out to him that convention over the years has been that classes ending in '-able' were usually interfaces, or might be suspected to BE interfaces by other programmers looking at his code.
English is a limited language.
Is 'Manager' suitable for the name of a class or an interface?
If only the latter then what do I call a class that represents something that "manages"?
He said he didn't care.
I then later noticed he had an interface defined in another package called 'Createable'. So he had made two classes of the same name in different packages, one an interface and one not.
Our boss doesn't seem to mind this kind of thing (he just wants us to get the work done and isn't interested in quibbling over things like naming convensions). Perhaps I'm a bit stern about these kinds of things, but it really gets my goat when this happens.
What's your opinion, Java Community?First it is a management problem.
Second there are proven techniques for producing better code. Coding conventions are not one of those.
Third if an organization is such that it is using other proven techniques, then coding conventions might have some measurable impact on quality, but lacking other techniques (or lacking all techniques) there can be no measurable impact as it would be less than the noise level caused by other correctable items.
Fourth as a point about what measurable techniques are the classes that the developer is creating actually Objects (Object Oriented Objects)? Versus random collections of functionality for example? The latter would be a far more serious problem than naming. And does that developer, and all of the other developers, use inheritence appropriately? Again misuse there would be a far more serious problem.

Naming Conventions of Web Dynpro Wizard

Hello everyone,
is it possible to change the naming conventions of the coding generated by the web dynpro wizard?
According to our internal naming conventions object references (type ref to) are to be named LR_name, but the wizard is calling them LO_name.
Thanks in advance and best regards,
Alej

The templates/code fragments used by the wizard for generation are in the class CL_WDY_RG_FRAGMENT_TOOL, which in turn navigates down to local classes in the WDY_RG_CODE_TEMPALTES Function Group. For instanace the Context code fragements are in the local class LCL_COMPLEX_FRAGMENTS of this function group.
The fragements aren't in reusabe or customer maintable templates unfortuetely. They are built with CONCATENATE statements in these local classes. Newer developments (like the ABAP Code Completion in 7.02) use the ABAP Template Language (ATL) and have a tool to maintain these templates directly. However for the WD Code Wizard, you would have to use the Enhancement Framework or Modification Assistant to adjust the concatenate statements in the local classes.

Naming convention concerning interfaces?

Our trainer suggested to use the naming convention ifa for interfaces, for example ifaCar or ifaTree.
Does this make sense?
Please answer as many as possible.

What does an "ifaCar" do? It should describe what it does. So any class that implements "Printable" can be printed.
Meaning it does not really matter if you name it "ifa..." just to know it is an interface.
cheers
Jonas

Enterprise Object (EO) Naming Conventions for Controls

Post Author: rnagahori
CA Forum: Nsite
When naming controls you should follow standard naming conventions. Good names
describe the control, such as prodName, effectiveDate, and dateRequired. Avoid
special characters like "-" ," /", "<" , or ">" when naming your controls.

Post Author: rnagahori
CA Forum: Nsite
Additional notes ... Avoid using the following list of Reserved Variable Names:Application Builder uses several reserved variable names. Please do not use
these as the names of controls, or as variables within Action Builder
routines.
Reserved Names
sum
min
max
avg
abstract
boolean
break
byte
case
catch
char
class
const
continue
default
do
double
else
extends
false
final
finally
float
for
function
goto
if
implements
import
in
instanceof
int
interface
long
native
new
null
package
private
protected
public
return
short
static
super
switch
synchronized
this
throw
throws
transient
true
try
var
void
validate
while
with
_allowSubmitOnError
_fields
_form
_locked
_name
_queue.errorFields
_queue.errors
_queue.validation
_parent
_pointers
_showAlerts
_skipValidation
_status
obj
addEvent
addField
addMethod
addValidator
changedFields
checkForErrors
disabled
dump
forceValidation
hasChanged
getFields
optional
onSubmit
onValidate
removeField
required
reset
setFields
submit
submitCheck
description

Class naming convention

Similar Messages

Maybe you are looking for