Comments embedded. On Fri, 19 Aug 2005 10:36:52 -0500, "Dennis Williams" <oracledba.williams@xxxxxxxxx> said: > I used to work for a software vendor whose policy was "*no comments in > code* ". It is obvious that this company has not hired guys who will go to *any* extent to keep their job like declaring variables as l_mc_tmp_1_qp and writing like if l_m_tmp_ac = 2 update <table_name> set flag='R' end if Handover such a code to the software company you worked and see their reaction. Documentation is a must. No if's and but's. I would appreciate any setup where they insist on code review + documentation. > Usually I'm a real documentation kind of guy. So I was a bit shocked > at this policy, to say the least. And this job was writing C code > which doesn't have a reputation for self-documentation. After working > there for awhile, I gradually began to see the wisdom of their policy. > Consider these points: > - Comments can be a crutch. If a programmer is forced to rely solely > on the code, then you tend to make the code more self-documenting. > Perhaps instead of selecting "A", "B" and so on for variable names, > you carefully select meaningful names. Or write the code in a > straightforward manner rather than dazzling with arcane > constructions. > - Out-of-date comments can be misleading. People often modify code > but fail to modify the comments. > - Most comments are superfluous, of the variety "the following line > sums the values of A and B and stores the result in C", followed by > C = A + B. Having 7 lines of comment per line of code can end up > obscuring the code. Dennis Williams HTH GovindanK -- //www.freelists.org/webpage/oracle-l