currently every individual SAP project in a big IT firm has its own project specific naming convention and code quality standard. if an IT firm has 20 SAP projects running then 20 different project standards are prepared by each manager inspite all 20 projects are involved techanically and functionally in same technology. i explain why we DON'T need different project standards for same technology. how does one common standard applicable across all projects in a big company improve the desired level of code quality, code readability for all SAP developers in a company and easy adaptability of developer across all projects without wasting 2 -3 days reading same documents? i have worked in four SAP projects and observed various contradictory code quality assurance standard.
(1) in my previous project, use of 'field-symbol' is not allowed. although in my present project, use of 'field-symbol' is highly recommended to replace 'work-area' and data manupulation in internal table without 'modify' statement. utility of this tool is immense other than stated two ovious scenarios.
(2) in one project, it is ok to read an internal table using 'Binary Search' always and religiously. but it doesn't make sense to read an internal table using 'Binary Search' for once or twice as 'Binary Search' requires 'Sorting' which itself is very time consuming. in such case, linear search is good performance wise if requirement is not beyound 4 times or read inside loop itself.
(3)another contradictory thing i noticed that one project allows 'modify' satement with 'where' clause for internal table inside loop while other project rates it as bad coding style as modify statement works in linear fashion starting from index 1 to n which unnecessarily increases record (internal table) processing time. so, how do they suggest to modify internal table ? take one scenario: based on outer looped internal table1, if one has to modify the content of internal table2. then sort the internal table2 outside loop based on conditional fields. read this internal table2 inside loop assigning field-symbol based on conditional fields. if it finds a record then simply change the content of field-symbol which gets reflected in internal table2. so, basically one replaces linear processing by sorting+binary search. latter is good performance wise if records are in great number in production system.
(4)one project allows to modify database table in 'user-exit/BAdi' directly where as other project doesn't allow it without 'update perform/update function' module because it violates the concept of 'All or None' database update. as previous approach will lead to inconsistent database if respective standard transaction fails in middle of processing before executing 'commit' statement.
(5)one rediculous thing was-one project didn't prefer 'inner join' because QA guy feared that it might lead to data loss in complex situation. priceless!!!
bottom line is that each has developed one specific standard QA list which reflects limitation of one's knowledge. sad part is this kind of industry practice at project level is common everywhere. one effective solution can be that only few selected efficient techanical experts of company should set the standard of code quality for all projects. It will easy to implement best industry practices in SAP technology as ignorance of latest update in technology as well as lack of wider exposure are reason for this inconsistency.
I am not able to appreciate the benefits of following different naming conventions for different projects in a same company. as far as functionality and performance of codes are concerned, it is not going to alter anything. so, sticking to one standard for naming will enhance more standarisation of code maintenance. when client buys a specific namespace from SAP then accordingily the naming can be changed while maintaining rest things intact. as for example, if a client wants that all custom developments shud start with 'PPP' initial then what one has to do is just add this initail 'PPP' to custom name using already fixed one naming convention.
15 comments:
As far as naming standards are concerned SAP more or less maintains a unique set of standards with a slight variation viz, for declaring internal table it_ or t_ etc.
However, concerning your coding standards across the 4 projects you have been into is absolutely dependant on your understanding of each concept such as , field-symbols, user-exit etc. in your case.
Before you use any concept in your program make sure you know its A to Z concepts aptly.
I am sending across an attachment to your G-ID where you find an eplanation for all your questions.
Touch-base with me in case of any ! :-)
Make sure that after you run through those points you need to be extremely tough with your debates/arguments over the usage of those skills and stick to the same, whereas you sound a bit diffident when you expose yourself to your superiors/peers etc.
Cheers :-)
agreed, about the naming conventions atleast, but what happens most of the times the Docs are prepared by some 3rd party, then such kinda probs arises, why don't we place some global rules, regardless of projects and companies.
As far as naming standards are concerned, projects will have their own depending on who implemented the project. Once the implementation is complete and the project moves on to enhancement mode/support mode and taken over by a different company, then the latter has to follow the standards set by the former/client for consistency reasons. Latter may not have much say in this unless the existing standards are really bad. Which is rare, given that most of the comps maintain some level of expertise. But if we implement a project from the scratch its our responsibility to propose/discuss with the client the naming standards to be used in the project. If we are given the option, I think we do have a global standard for the same in SAP practice in our company.
Regarding coding standards, if you think a particular approach is not correct or have better approach, you can always challenge the existing and get the standards changed. These things always change for better. I have seen multiple projects using the same standards and improving them for every new project.
I believe it entirely depends on your drive and ofcourse your superiors too ;)
umm.... i suggest you add a little backdrop for junta not so familiar with SAP and its implementation...?
Ritz..
Most of the points you mentioned here is valid. There is only one rule for efficient coding.... " Apply your knowledge" ..... All the constructs in SAP is developed for certain cases... Even many of them are out-dated may be.. we have to filter out the outdated one's and we should be up to date......
Naming convention:
You are forgetting one thing. You work for your clients. Your company works for your client. Naming convention are decided by the clients and generally they do not differ that much.
Regarding other standards like performance issue related.
It is good that you are learning different view points from different project.
But most of the times it is ignorance of the person doing your review which leads to the confusion. Who ever recommend a a sort in a loop + binary search is wrong. Likewise if there is table can be sorted outside loop then binary search is better. Goes for everything else. I dont know much (not more than you).. so i cannot answer to all your confusion but if you do the research and then i think you will find there is not much difference related standard performance checks.
""Who ever recommend a a sort in a loop + binary search is wrong.""
you have mis-interpreted my point.
i have pointed out that binary search is specially needed when u have to read internal table inside loop. so, sort table before loop.
@ Rajapaga
i appreciate ur point that one shud know A to Z concepts aptly before one starts working on program. but my point is that how can one understand or realise that he/she is doing sub-standard coding when reference project QA standard itself is sub-standrad.
The scenarios you have mentioned here is compleatly dependent on the project.
For example field symbol: It is memmory efficient no doubt, but for some projects we need extensive 2nd level support where the use of field symbols will cause havoc.While for other projects,one time done is done.
It generally happens when the support is not taken by the same company.
And I dont know what is standard SAP naming convention.As far as I know SAP never released any Book on variable naming conventions.
Its totally decided by client so that they can maintain the same across various service providers.
Yes Inner join leads to loss of data but it is memory efficient, I dont know what made you QA for such announcement.Its totally developers decision .
By the way I too agree with your points. I am also a victim of it :D.
Aha..there you go...
Its not just your confusion but I beleive sometime or the other, every developer faces this dilemma.
As far as naming convention is concerened, I beleive SAP does follow some kind of naming convention if you watch there developments minutely. But thats probably used for SAP internal purposes. SAP can only propose a naming convention but cannot really force anything. And besides, as someone said before, its what the client asks for. So you cannot really have any particular kind of naming convention.
Coming to your second point. And probably the dilemma faced by all developers world wide. What I felt in my last four years of ABAP development is that there is no fixed rule. How a code performs depends on many things. And I beleive even the hardware has got a role to play. Other than few basic stricly NOs, there are no specific rules and regulations. Some may beg to differ with me but my personal observations have inffered so.
Yes there always have been a big debate over FAEs (For All Entries) and Inner Joins. Here again you cannot actually say that one is better thean the other. In a relational database system where two or more tables are related, then sure you should go for Joins. And I think the memory issue that inner joins lead to loss of data, I am not sure of that.
The bottom line is you have to be flexible in your thinking process. You cannot just stick to something and be foolhardy and not beleiving anything else. Use your own judgement, perception and experience.
@ pratyush/pratick
field-symbol is just a tool provided by SAP for abap development. I agree that if one needs modification in the existing codes then replacing work-areas or other stuffs may lead to unconsistent code design. but if it is new program or object one can simply use this tool even in 2nd level suport projects. if someone uses till tool (field-symboll)in wrong ways then it is fault of mechanic...not of tool.
my understanding of inner-join is that if u face data-lose in inner-join select then u must be not considering full primary keys of atleast one of the tables considered for join consition as well as hierarchy of tables. again i find...wrong use of inner-join leads to data loss. because SAP itself would not use this query in its complex programs.
Generally we go for "For all entries" most of the cases only because it is easy to understand the data retrievel sequence. it is nothing to do with better performace with respect to inner join.
Well Ritesh, you do have raised pretty pertinent points with regards to the naming and coding standards and ideally such a universal naming convention should be in place. To ensure such level of quality in typical IT companies where scores of projects are being delivered simultaneously, proper planning and investment(regular training, certification, etc) is required. One would need bigger quality teams and more frequent quality checks. Ideally there needs to be a dedicated quality team(1-2 members) for every project who will maintain the standards throughout the project realization phase.
Coming to the field-symbols, i think it is very important for the developer to make a judgement for it. Undoubtedly, it improves the performance of code as the system doesn't need to go to database layer to fetch the data, but overusing the tool may cause maintenance issues later. Field-symbols make the code much more complicated and in the support phase, it can become a pain-point for someone trying to resolve a complicated L1 ticket in an hour so.
Regarding binary serach, i totally agree with you that it is useful only when one has to read an internal table within a loop. I have seen enthusiatic developers using it everyime before reading an internal table, thinking that it improves the performance, but little do they realise that every Binary Search is preceded by a SORT statement. Fortunately or unfortunately SORT is a keyword in ABAP.This possibly hides the fact that it is regenerated into a small function at a lower level.
A sort + binary search, in best case, takes time of the order of Nlog N + log N while a simple read statement in worst case takes time in the order of N, where N is the size of the data set,i.e. no. of internal table rows.
Clearly, (N+1)log N > N for a single table read.
But if the table is read multiple times(say r) in a loop of another table:
Binary Search takes Nlog N + r.log N time
Simple read takes r * N time.
Clearly, Nlog N + r*log N < r*N, for a higher value of r.
What matters is how efficent your code is and how much flexible it is for maintainance and future requirements.
Rest all is fancy of clients and your superior which you have to deal with.
Also I would like to mention.
Inner join: selects all the common entries from two tables.
Outer join:(left/right): Selects all the entries from one table and common from another table, and will replace with null entries not found in another.
Data loss in inner join will take place when: All the fields you are trying to fetch is not mapped.
Outer join is needed when you could not map all the fields you want and you need all the data for one field ,not mapped, in one of the table.Mostly the case appears in hierarchical data model where all the data from parent table is mandatory to be fetched.
Post a Comment