Hi Daan and Luc, Its a very interesting topic. Personally I have always been used to "document" my changes "in code". In most of the projects I've been on, it has been mandatory, in one way or another. Typically a // BEGIN // END something with a change reference, and then the same change reference in the Documentation trigger, with a description. But each partner or customer typical a special way, they want it done. A simple and usable solution for most Navision implementations. Here you have to think about that often, then a customer may have different partners involved who each have their way of doing it. Sometimes these old "real life" customers have a chaos of different changes, and no real documentation is made to the customers (and if they did, then nobody knows where to find it). On the other hand, then I also agree that "comments are evil"! Because yes, they are very often misleading or wrongly used, or trying to hide badly written code. But that's not really the comments I'm relating to here. The // BEGIN/END comments are in my world not real comments. The reason we need them, is that most customer projects or partners, do not use source code control and tools like Team Foundation Server (TFS). I know that both Søren and you Luc are a lot further ahead of the rest of us, when it comes to that subject. [;)] So I'm happy to see Luc that you still think that this type of comments is fine. So my advise to you Daan, whenever you start on a new project, then ensure which "comment standards" are to be followed. On bigger customer projects with in-house NAV staff, then they often have their own, otherwise the customers partner have the standards.
↧