-cvs, -git, -snv... is really a good naming convention?

The unstable packages have the name of their relative stable one with added in suffix the concurrent version system installed.
I think it is a bad convention since it mixes implementer choices with the the concept of lastest unstable version.
I think it is better decide a single suffix (e.g., -unstable or -dev) and always use it without difference between the implementer choices of programming.
Moreover it avoids renaming headaches if someone changes program for keeping versions.
No flame wars. I decide nothing. It is only a thought.

Profjim wrote:
I've seen this discussed before on the forums...
Edit: http://bbs.archlinux.org/viewtopic.php?id=25938
I found this in the forum search: http://bbs.archlinux.org/viewtopic.php?id=25938
It doesn't seem like anything came out of that discussion. I haven't really found the naming convention confusing; it is the large variety of SCMs that is confusing, and that is not going to change anytime soon. The current package naming conventions are unproblematic for me so you'd have to point out exactly where a real problem has cropped up.

Similar Messages

Storage Location Naming Convention without WM!

Dear all
We are facing serious problem in our Storage Location for Raw Material.
We have 4 types of Raw Material Seating (S), Panel (P), Metal (M), Wood (W). And they are all stored under Storage Location: RWSL.
Requirement:
Although we have visual guideline as to which industrial rack will store the type of Material, it is insufficient. We need a more refined storage location down to which BIN of the rack we will put the Raw Material.
Due to limited time and resource, we cannot have WM implemented right now. Thus, we have come out with 2 alternative to overcome this problem:
Alternative 01:
We will use the Fixed Bin field in Storage Data 02 by putting the Bin number assigned to each Rack.
E.g. For Seating material code:SEAT01, we will maintain the Fixed Bin as R12A01/A02, it means this Seating material SEAT01 will be stored at Rack 12, fixed bin A01 or A02.
Question to Alternative 01: Will it cause problem in GR, GR, Transfer Posting and Stock Count?
Alternative 02:
Instead of going into details to put Fixed Bin field in Storage Data 2, we will abandan the existing Storage Location RMSL by introducing new format for Storage Location
Here is the example of Alternative 02:
For raw materials, we will use 4 digits location numbers, consistent with other Storage locations, the 4 digits storage location will start with u201CR _ _ _u201D to represent each location
And,
R _ _ _ is:
R = Raw materials
2nd digit = Division (S= Seating, P =Panel, W=Wood, M=Metal and W=Wood)
3rd digit = Rack Number (A, B, C, Du2026 and etc.)
4th digit = Rack Zone - each rack will broken down into zone, each rack can possibility have 2 to 3 zone. 1 Zone can be 1 colume of the Rack
An example of a possible location and its meaning will be
RSA1 = Raw materials warehouse, Seating division, Rack A, Zone 1
RPB3 = Raw materials warehouse, Panel Division, Rack B, Zone 3
The challenge of this is that instead of having 1 Raw Material Storage Location like RMSL, we will have a lot more storage locations each for division of Raw material due to the Rack Number we have as well as the Rack Zone.
Question to Alternative 02:
If we use this alternative, will it impact our future implementation of WM? From design wise, is it feasible?
Please advise what is the best approach and the feasible design on it.
Many thanks in advance.
Edited by: Daimos on May 13, 2009 10:15 AM

Hi, here is the Pro and Co of both approaches:
Method 01: Use existing SLOC and add the Storage Bin info
e.g. SLOC: STM1
         Storage Bin: RSC3, where RS = Rack Seating, C3 = column 3
Pro 01:
It will cause less effort as we only need to use LSMW for material master to add in the Storage Bin data for all material of SCM.
Pro 02:
I have tested out that in TCode MIGO, apart from SLOC, the pertaining Storage Bin data also appear. Based on my discuss with Xian Chen, sometimes they use MB1C(GR), MB1A(GI) rather than MIGO due to speed issue, I will need to check the field status if can have Storage Bin field APPEAR, if can, it will solve the problem
Con 01:
The Storage Bin information will only appear in MMBE (Stock Overview) but will not appear in the standard SAP Inventory Report (e.g. MB52 Warehouse Stock). To view it from SAP Inventory Report, we may need to customize the standard report to show the new field Storage Bin. It needs Abap effort.
Con 02:
We must have a very good naming convention for Storage Bin. And again, in the above example, if a material is put in SLOC STM1 at Storage Bin RA A1 or C4, it will set a very rigid rule in the future if we need to change it, as I fear that one the Storage Bin has been used up. It will not allow us to change (need to do testing to find out)
Con 03:
Do we have the time to define all the Storage Bin for each SLOC? Operation wise, the store personnel needs to design it
Method 02: Use the new SLOC
Pro 01:
RSA1 = Raw materials warehouse, Seating division, Rack A, Zone 1. More organized. Easy to tell the material is at which Rack and which Zone of the Rack.
Assumption:
01. we must not have too many rack for one Seating division and also not too many Zone for each
      Division, else it will cause confusion
02. 1 material should stick to 1 Rack 1 zone as much as possible, else later the PP consultant will
     have hard to to perform GI due to too many SLOC assigned to a material.
Pro 02:
In report wise, we are able to show the SLOC in inventory report. No need to enhance the existing inventory report as we do not use Storage Bin.
Con 01:
If there are too many SLOC creation due to it. It may cause problem for PP perform GI as too many selection available for a material. This can be avoided if stick to the General Rule that one material is tied with one SLOC.
Edited by: Daimos on May 16, 2009 5:07 AM

Data Modeler - Naming Conventions

I was using Oracle Designer for several year.
This product could drive you crazy because sometimes, but the strength was in my opinion the datamodelling part.
It saved you a lot of time because you kept stuck to the logical model generated your relational model and had all scripts satisfying all naming conventions you needed.
In Data Modeler i really miss the naming conventions and can't understand some parts, sometimes somebody here can help me if i have overseen something or it is just not implemented.
Naming conventions as example:
We work with surrogate keys.
Two well known tables - Employees (abbreviation EMP), Departments (abbreviation DEP)
They have one relation 1:N one department has many employees
In Designer i would define the EMPLOYEE entity, would set the table-abbreviation, the attributes and the primary key.
The same with DEPARTMENT. I would design it WITHOUT any column for the foreign key constraint.
Then i would create a relation between this two tables.
Last step is to generate the relational model.
a) Designer automatically adds ID as surrogate key on every table (you could configure that, it was dependent on a domain)
b) it automatically adds the table abbreviation as prefix on every column (even here it's configurable)
c) it automatically adds the a foreign key column in the child table with the prefix of the master table (f.e. EMP_DEP_ID or DEP_ID if you prefer not to prefix every column... what i do)
It was really easy to get your scripts.
Things i don't understand in Data Modeler:
In a logical model you should design entities, attributes and relations and don't mess around with FK-columns.
Is there any support for surrogate keys? I don't wanna add an ID manually with every table.
In Data Modeler an additional COLUMN(!) is added with every Foreign key relation, i could live with that, but there is no way to tell
Data Modeler to prefix it automatically. The name can just be changed in the Relational View afterward.
P.S.
Surrogate Keys.... There are some pros and cons for/against this out there. I have seen a lot of Oracle Projects and in all except one i always had a surrogate key column. It really makes life
easier. In the one no-surrogate-key-project we began to add surrogate keys after a while...

COLUMN(!) is added with every Foreign key relation, i could live with that, but there is no way to tell
Data Modeler to prefix it automaticallyLook at "General options>Naming Standard>templates" - you can define template for FK columns/attributes and then apply them for whole relational/logical model using "Apply Naming .." functionality from pop-up menu in the browser. For Logical model (FK attributes) - you also need to clear related setting at "General options>Logical>Keep as the name of originating attribute".
Templates are also used when objects are created, thus when new FK is created, then templates are used to generate name for foreign key and FK columns. Well you have to define table and column abbreviation in order to get them used in generated names - Re: Data Modeler: Naming
There is no support for surrogate keys in current release.
Philip

Naming Convention (Naming Rule) for CAF GP

Hi, all.
Is there any naming convention for CAF GP?
For its process, action, callable object so and so.
Web Dynpro for Java has very good naming convention like the following.
http://help.sap.com/saphelp_nw2004s/helpdata/en/e4/d7fb402eb5f76fe10000000a1550b0/frameset.htm
Could someone provide the information?
Best Regards.

Hi Sejoon,
Sometimes I see GP provided coding examples and it seems that GP does not have some specific naming convention. It's clear that they use sdandart java naming convention. So, you can use it too.
Best regards,
Aliaksei

HT2534 in my iphone5 'none' option for credit card is not being appeared. May be because of software upgrade or wot it is really not good as i don't want to share my credit card number.

the 'none' option under payment methods is not being appeared in my iphone 5 as i don't want to share my credit card info. and my id stuck over that point as i am not abble to skip this step and it is a must option to select a credit card type and give a real credit card details. This is really not good.

You have to enter your credit card number and some amount would be debited from your account(60 rs in india)
After registration, You can Go to
1 Settings
2.Itunes&App Store
3.Click on your apple id .
4.Select View Apple ID
5.Slecet Payment Info
And You can find NONE here.
Please select NONE to delete your credit card numbe r from the list
But While registering you cant find NONE, you have to enter the cc number.
Thank You
Tejas

Is mac keeper really that good?

I currently use Tech Tool Deluxe but am considering purchasing Mac Keeper. Is this application really that good? I know that "good" has many interpretations but overall, I'm interested in hearing peoples' feedback on the app in general. Thanks!

Search the forums, you will find the consensus that Mackeeper is not a good idea. Not a good idea at all.
As far as I can tell, this product is a combination of new interfaces for standard mac stuff (e.g., they have a Login Items interface for crying out loud) and a bunch of utilities you might need if you were running windows but which, generally speaking, are completely unnecessary for the typical user.
In fact, it seems to me that, unless you have some very specific problems, "system utilities" are unnecessary and principally aimed at a former windows-user market.
charlie

Is the Apple iPod AV Cable really that good?

My dad and mom are suppose to be bringing me home the Apple iPod AV Cable. I bought HS Musical from iTunes and they had never seen it, and want to, so I told them about the cable.... but anyways... I read the reviews for it, but I really want to know does it really have good video and sound quality?
I mean I will be hooking it up to a 32" Sony Trinitron (Wega) tv and I want it to look good and sound good...

Also, connecting to the cable to an Apple Universal Dock (with the iPod docked (instead of connecting it directly to the iPod)) will make the sound and video better.
btabz

Buy a headphone, Is B&W p5 really that good? Please suggest headphones

I would like to buy a headphone, I hear orchestra/new age more and I hope he headphone will fit these styles, if there's any headphone that can enhance orchestra/symphony and make the music even more beautiful? Is b&W p5 really that good and worth the money?
Thanks!

Hi,
So, they didn't do anything about it since original Z came out? If the problem is well known, it should be fixed :/ I just checked my Z2 against iPhone 5S with P5 headphones and since iPhone is not as loud as HTC One S, it is a noticeably louder than Z2.
Dedicated dac-amp sounds fine but it is another component and I would have to fit all this somehow in my pocket. Sounds like a bulky solution for on the go mode.
Anyone from Sony can say something about this?
Greetings,
Luke

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.

Do you have suggestions for naming conventions within AIF?

Hi Folks!
Being new to AIF I'm currently in the information gathering phase for myself and colleagues as we are starting to think about implementing interfaces with the help of this toolbox. I already found and read (or at least skimmed!) through various of your discussions as well as the very helpful blog posts from Verena, Michal and Andrey.
One of the first things we want to do - before we really get started for real - is to come up with some feasible naming conventions for the various customizable bits and pieces like
Namespace
Interface Name
SAP Data Structure (if applicable?)
We also have some general questions:
Does it make sense to prepare for one namespace per SAP-module or is it better to have just one and do the separation on the Interface name "level"?
Is it preferred - even though SAP doesn't seem to enforce this - to start our own names with a "Z"?
Searching SCN for "naming convention aif" didn't find anything related and while scrolling through the discussion forum I also didn't see any titles which might go into this direction. In order for us to not re-invent the wheel - or to start off in the wrong direction - I'm hoping to get some helpful pointers from you.
Thanks much for any feedback you have!
Cheers from Germany
Baerbel

Hi Bärbel,
Your question is very good. We had the same and decided for following own approach:
Namespace
A Namespace is a concatenation of business process and SAP module, e.g. O2C_AR, P2P_AP, P2P_MM, R2R_GL.
We have one global namespace for global objects as checks on currency code, date format value mappings, etc.
Interface NameEvery interface has its own name. To be honest for inbound interface the names are more a user friendly description, for outbound we follow a little rule that they start with OUT_.
SAP Data Structure (if applicable?)
We try to do the structure mapping in the middle-ware and AIF is only responsible for the functional mappings.
The root structure name is different between raw data and SAP data. But the sub structure and field names are equal. Because of this we can use the move corresponding fields or in some only monitoring interfaces even move corresponding structures.
We also have some general questions:
Does it make sense to prepare for one namespace per SAP-module or is it better to have just one and do the separation on the Interface name "level"?Because AIF support and business users differ in different business processes we separated in these processes and modules. In addition the recipients groups are similar to the name spaces.
Is it preferred - even though SAP doesn't seem to enforce this - to start our own names with a "Z"?For namespaces (six characters) and interface names (10 characters) we don’t.
Best wishes
Christoph

MSI naming convention

I just got a K7T266 Pro2-UL (MS-6593). Searching in MSI's web I found that there is another mobo with the same reference (MS-6593): KT3 Ultra2-C. They are clearly different, even one is based on KT333 chipset while mine is based on KT266A chipset.
After I realize this is not the only case. This fact is really inconvenient because it could cause serious problems (I read in another forum some cases of wrong BIOS updating due to very similar motherboard names).
Is there any reason for that naming convention?

Hi,
Yep, you are right, the naming of MSI boards is really bad :D
The example you gave is a good one, but the 2 boards are a different version.
It's even a bigger mess then that :D
We asked MSI a long time ago to give at least very board a unique MS-XXXX number so that there can be little confusion.
But it still didn't change....
At the moment there is just 1 way to be sure of what BIOS you need for what board....
And that is by checking the MS-XXXX and Version number, only then you can be sure you get the right BIOS..

Oracle Naming conventions

Hi everyone,
I wanted to ask you about Oracle Naming Conventions. I've found a lot of stuff on the internet. Here's a short summary of what I've discovered so far...
These are absolute:
1- All names should be between 1 & 30 characters (database names accept 8 characters max)
2- Names can not be duplicated in the same namespace
indexes, constraints... are in one "schema" namespace
tables views... are in another "schema" namespace
3- Only letters (lower & upper), numbers and $, # & _ are accepted in a name.
4- Quoted identifier are case sensitive and accept all kind of characters.
The previous rules can not be violated otherwhise the object won't be created.
Now they are a lot of naming conventions...
- Always use a plural names for table (USERS i.o. USER)
- use a prefix or suffix in constraint, indexes, ...
USERS_PK, USER_IDX...
I want to talk about these. What are your own naming conventions?
Thanks

user13117585 wrote:
Hi everyone,
Well actually I am currently trying to make a document for my company. All the developers will need to follow the rules I'm writing.
"It's good to be the king!"
My problem is that, I have many databases with hundreds schemas and I want to normalize everything (no only me want that but the management too). Anyway,
- Some people are still using only 8 letters for object names (tables, views, constraints...). Names are cryptic. I spend like an hour to understand what means DRPOLDSZ. And table columns are also limited to 8 characters (what could DELLOLCN mean??)
- Some developers are using other conventions. A good Table example would be:
TABLE DOSSIERS
DOS_DOSSIER_ID
DOS_NUMBER
DOS_CREATION_DATE
I hate that prefix in each column too;
As do I. Going back to data normalization .... the prefix adds nothing.
>
- Some developers use other conventions
some have table names in plural, others singular
some don't use the _ to separate multiple words object names, some well
some prefix table id some use postfix (id_table vs table_id)
etc etc.
I want to normalize all the databases to use one and only one convention; I already thought about it and wanted to know what you all have in place; how do you manage to have all your developers using the same conventions ?
About [ http://ss64.com/ora/syntax-naming.html| http://ss64.com/ora/syntax-naming.html] (1) article, I've read it but, I don't agree with the guy on everything. He mostly uses prefix (pk_Table, idx_table, fk_table). When you give some thoughts, isn't it better to use suffix?
Table_PK, Table_IDX, ...
When you do a query on ALL_ or USER_OBJECTS, you can order them on OBJECT_NAME and have the name groupped together.
I also prefer to have in the constraint name the base table and the referenced table. Instead of what the guy propose FK_TABLE_NAME, something like TABLE_NAME_REF_OTHER_TABLE_FK
Well, you don't have to slavishly follow anyone else's document. Again, you are using those for ideas. In the end, you need to do what makes sense to you. Also realize that having A standard - almost ANY standard - is better and more important that sweating the pros-and-cons of any particular detail. Just make a decision and go with it. Get management to sign off on it as the standard.
My question is not really a question but more a how do you handle all kind of developers and what is the best way to force them to normalize and use the same conventions...The only way to force it is to take "CREATE object" away from the developers. This is actually done in many shops. If you can't do that, then at least set yourself a task of auditing and going back to violators. If you get some recalcitrant violators, elevate it to management - who you had sign off on it.

Looking for best practice on naming conventions

Does anyone out there have a best practice on naming conventions that they could share.
I'm starting to find the need to create objects and associated variables and actions.
I can see this getting very messy, very quickly and would love to learn if someone has come up with a good set of guidelines that are both easy to follow and make perfect sense. (I know....what a balance to ask for!)
Thanks
Alan

Hi Alan,
Welcome to Adobe Community.
There are couple of things that you can keep in mind while naming objects.
When creating custom text caption styles, be sure to follow the correct naming conventions. Each caption style has a unique name, and you must
use this name at the beginning of each associated bitmap filename. For example, if you create a text caption style named “Brightblue,” the five
bitmap images that constitute the new style should be named as follows:
Brightblue1.bmp, an image with no callouts
Brightblue2.bmp, an image with a callout to the right or upper-right
Brightblue3.bmp, an image with a callout to the left or upper-left
Brightblue4.bmp, an image with a callout to the lower right
Brightblue5.bmp, an image with a callout to the lower left
Flash button-naming conventions
Each SWF button contains three layers: a button, an icon, and an action layer.
The SWF filename consists of the following elements:
Acronym for playback control (“pbc”)
Playback element identifier (“Btn” for button, “Bar” for bar, and so on)
Name of the button (“play”).
Hope this helps!
Thanks!

Preferred package naming conventions for plug-ins?

Every combination seems to be in use already...
VIM plug-ins are vim-plugin_name
XFCE plug-ins are xfce4-plugin_name-plugin
GIMP plug-ins are (mostly) gimp-plugin-plugin_name
I plan on making some plug-in packages for a application what dose not currently have any available. So as the topic says what's preferred package naming convention? I personally like the GIMP format best but just figured I'd ask first (should really be in the guidelines IMO).

Ok well I guess I'll use the third option for now them.
While we're talking about naming conventions I was just searching for the python cairo library noticed binding library's could do with some guidance to...
cairo-perl
pycairo
ruby-rcairo
IMO language-library_name would be a nice guideline.

-cvs, -git, -snv... is really a good naming convention?

Similar Messages

Maybe you are looking for