Hi Raul,

yes it should always be partner's initialls and not
customers. 

     But suppose if you are directly working for an
end client then you could have their Initial. This is
to identify what's standard and what's new.

If your firm has got some outsource work then the
client (which would be an MBS parnter) would always
suggest to have their intials.

When i was working for my ex-employer we used to get
many developement work outsourced by some solution
centres in the US and other countries. They always
wanted us to use their initials (in fact this was one
of their requirement).So this would mean that these
organisation would have a unique initials , no matter
if it was outsourced or work was done inhouse.

   this we did  since way back when we used to work on
version 2.1. This was the requirement of most of the
Solution centres. In this way i cultivated the habit
of adding the prefix as a rule for naming.

  Guys, I am not saying adding suffix or not adding
any identification is wrong. Every one is RIGHT in
what they follow. This is not any individual's
decision. This rule is always decided on
Organisational level, whether if we need any
prefix/sufix added as a rule for naming conventions
and all the developers , within the organisation, have
to follow this rule. 
     As a technical consultant all i could do was give
advise to our clients and it was upto the client to
decide.

    But i felt this was a very good discussion and i
am sure we all will be benifited from all the views.  

   Have a nice day!!!!

cheers,
Girish


 --- Raul Llorente Peña/OPENSOLUTIONS
<[EMAIL PROTECTED]> wrote: 

---------------------------------
The problem of prefixes comes when you want to copy
funcionality from a customer to other, and have a
maintenance plan on them...
customer 1: Pelbet    Prefix: PLB_
customer 2: Ibmosher Prefix: IBM_
 
Object: PLB_Class1, PLB_CustReport, etc...
Export them, import in Ibmosher... objects called IMB_
with others PLB_ make no much sense... rename them
before importing, or after exporting... ok, now
objects have the right prefix... Pelbet suddenly
complaints about a bug, or want to add funcionality...
Shall I rename every corrected object in every
customer with that funcionality????? Urgh, that
doesn't sound clear for me.
 
An intermediate solution could be to prefix objects
with the Partner initials, instead. I don't use to
prefix objects with company names (customer's nor
mine).
 
Raúl Llorente Peña 

Análisis, Desarrollo e Implementación en 
Microsoft Bussiness Solutions-Axapta
OPEN SOLUTIONS


-----Paulius Cerniauskas <[EMAIL PROTECTED]>
escribió: -----

Para: Axapta-Knowledge-Village@yahoogroups.com
De: Paulius Cerniauskas <[EMAIL PROTECTED]>
Fecha: 18/02/2005 09:43
Asunto: RE: [Axapta-Knowledge-Village] High
Importance!!!! Syntax error after a Int declaration.

You can find both advantages and disadvantages of
using prefixes. In my practice prefixes is good for
version control and client based object grouping.
Sufixes is good to trace inheritance, e.g. class or
EDT inheritance. As always it depends on your coding
style...
And try to get used to shortcuts F2, F11, Shift+F2
etc. I have found it very usefull...

regards....




> 
>  
> 
> Hmmm... are u a systems administrator by any chance?
> 
>  
> 
> Your reasoning is perfectly logical if one is
> thinking from system
> administrator's point of view.
> 
>  
> 
> For me as a programmer, it's the ease of reading the
> code and ease of
> upgrade that is more important. As said earlier,
> while reading the code,
> I don't want the prefix to interfere in my thinking
> and if I extend an
> Axapta table (new table to hold relevant
> information) or create an
> inheritance of a class then I want the new objects
> listed in relevance.
> (for e.g. I have extended InventMov_Purch class and
> given it the name
> InventMov_Purch_ShipmentMMS, this will make sure
> that my class is
> grouped together correctly.
> 
>  
> 
> Adding tables to data import export groups has a
> very limited advantage,
> how many times does anyone do that? And I never use
> the F2 (lookup)
> functionality for coding.
> 
>  
> 
> I was using a prefix in 2001 and have been using a
> suffix since then and
> I can confidently tell you that suffix will improve
> the coding speed in
> the long term. In fact all the solution centres that
> I have worked for
> have gone for the suffix. I would say try it for a
> week and see the
> results.*s*
> 
>  
> 
> Regards
> 
>  
> 
> harry
> 
>  
> 
>  
> 
>   _____  
> 
> From: Girish Bhatkal
> [mailto:[EMAIL PROTECTED] 
> Sent: Friday, 18 February 2005 12:41 p.m.
> To: Axapta-Knowledge-Village@yahoogroups.com
> Subject: RE: [Axapta-Knowledge-Village] High
> Importance!!!! Syntax error
> after a Int declaration.
> 
>  
> 
> Hi Harry,
>     from my experience i feel there is always an
> advantage of naming with identifier as a prefix. i.e
> if your client's name is ABCDE then you could pick
> the
> first 3 digits and then write "ABC_TableName1". some
> of the advantages are:
> 
> 1. if you want to include the new tables created in
> the defination group (to import/export the data)
> then
> its easier to understand which tables to pick.
> 
> 2. if you press F2 and want to pick up the new table
> created its easier to identify the tables as they
> all
> are listed one after the other. similarly when
> selecting EDT and enums from the short cut.
> 
>         There are so many other instances where
> adding
> the identification as a prefix would help a lot. It
> might be possible to even identifing by adding
> suffix
> but prefix makes things easier, atleast for me.
>      By adding the identification as a suffix we can
> maintain the other naming convention rule where in
> we
> add the prefix to identify the business area. But we
> could add the identifier then underscore and then
> the
> busniess area of the element. 
> 
> cheers,
> Girish
> 
> 
> --- Harry Deshpande 
> wrote:
> 
> > Hi Girish
> > 
> >  
> > 
> > "It is
> > always better we add some prefix so that it will
> > never
> > affect the standard functionality..."
> > 
> >  
> > 
> > Or may be use a suffix *s*
> > 
> >  
> > 
> > Regards
> > 
> >  
> > 
> > harsh
> > 
> >  
> > 
> >   _____  
> > 
> > From: Girish B [mailto:[EMAIL PROTECTED] 
> > Sent: Thursday, 17 February 2005 11:45 p.m.
> > To: Axapta-Knowledge-Village@yahoogroups.com
> > Subject: RE: [Axapta-Knowledge-Village] High
> > Importance!!!! Syntax error
> > after a Int declaration.
> > 
> >  
> > 
> > Guys,     
> >      This problem is one of the instance where the
> > naming convention what we follow affect the
> standard
> > functionality aswell.
> >    When ever we create/modify in standard axapta
> we
> > should be carefull of what name we are giving. It
> is
> > always better we add some prefix so that it will
> > never
> > affect the standard functionality...
> > In this example we all know that at many places
> > x,y,z
> > and a,b,c would be used so we should avoid using
> > these
> > for naming the new EDT. If you do want to display
> > x,y,z etc.. then you could label the elements with
> > these but the element name should be given a
> prefix.
> >     It is very important for new axapta developers
> > to
> > start using some standard naming conventions
> because
> > you will get used to this standard practice, else
> to
> > change in the later stage becomes a bit difficult,
> > but
> > still posssible.
> > 
> >      !!!!Enjoy coding!!!
> > 
> > cheers,
> > Girish
> > 
> > 
> > --- Padmaja Iyingar 

> wrote:
> > 
> > > Hi Preston,
> > >  
> > > Its perfect. Your assumption is right. I tried
> to
> > > change  to 
> > >  
> > > real _quantity, _price from  real quantity,
> > price..
> > >  
> > > ha ha ha ha..It wroks now.
> > >  
> > > Thanks Preston for the tip.
> > >  
> > > regards,
> 
=== message truncated ===


=====
Paulius Cerniauskas
Phone: +37062049339
ICQ: 280959446


    
        
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - You care about security. So do we. 
http://promotions.yahoo.com/new_mail


------------------------ Yahoo! Groups Sponsor
--------------------~--> 
In low income neighborhoods, 84% do not own computers.
At Network for Good, help bridge the Digital Divide!
http://us.click.yahoo.com/EpW3eD/3MnJAA/cosFAA/kGEolB/TM
--------------------------------------------------------------------~->


Sharing the knowledge on Axapta. 
Yahoo! Groups Links

http://groups.yahoo.com/group/Axapta-Knowledge-Village/

[EMAIL PROTECTED]









Sharing the knowledge on Axapta.



---------------------------------
Yahoo! Groups Links

   To visit your group on the web, go to:
http://groups.yahoo.com/group/Axapta-Knowledge-Village/
 
   To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
 
   Your use of Yahoo! Groups is subject to the Yahoo!
Terms of Service.
 


        
        
                
___________________________________________________________ 
ALL-NEW Yahoo! Messenger - all new features - even more fun! 
http://uk.messenger.yahoo.com


------------------------ Yahoo! Groups Sponsor --------------------~--> 
Has someone you know been affected by illness or disease?
Network for Good is THE place to support health awareness efforts!
http://us.click.yahoo.com/Rcy2bD/UOnJAA/cosFAA/kGEolB/TM
--------------------------------------------------------------------~-> 

Sharing the knowledge on Axapta. 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/Axapta-Knowledge-Village/

<*> To unsubscribe from this group, send an email to:
    [EMAIL PROTECTED]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 



Reply via email to