|
>would you like to try again? Nope, I wouldn't like to try again, and I still like mine better. I have a methodology for indenting just like you do, they are just different. I don't like to take up 20 lines of code for a couple of statements when I could take up 2 or 3. Here is my method: 1. If the line of code extends beyond 80 take everything after '=' and put it two spaces after the beginning of the line before it. batch.customerId = #CtoN(DOMXPath_getAttrValue(root: 'Batch/customerId': *Omit)); 2. If it still is too long take the parameters and chop them off and add them to the next line two spaces after the name of the sub proc. DOMParser = DOMParser_init( pSourceType: pSourceString: pValidate: 37: pErrorProcPtr); 3. If that is still too long I just start lining up the parms vertically until it does fit. DOMParser = DOMParser_init( pSourceType: pSourceString: pValidate: 37: pErrorProcPtr); 4. I put spaces after each colon to clean up the multiple parms on one line. There you go. . . Joe. . . To address Joes comment about my field names being too long. I agree here with fields like 'customerDivision'. I am just trying out how it feels to use long field names. I will most likely end up with 'custDiv' in the end because that relays the meaning of the field just fine. I have just ventured into the world of renaming my externally defined sub procedures (and data structures). I knew I could do it, but always strayed away from it because of having the prototypes defined twice (once in my program and once in the module with the external sub proc, we have used /Copy members up to this point). I definitely like the idea of renaming the sub proc to what I want it to be (kinda like instantiating, giddy:-), but it makes it a bear to find where certain sub procs get used if they are renamed. I suppose one could write a tool for that:-) Aaron Bartell -----Original Message----- From: rick.baird@xxxxxxxxxxxxxxx [mailto:rick.baird@xxxxxxxxxxxxxxx] Sent: Tuesday, August 05, 2003 4:27 PM To: RPG programming on the AS400 / iSeries Subject: RE: Adoption of new RPG techniques Aaron, yours? DOMParser = DOMParser_init( pSourceType: pSourceString: pValidate: 37: pErrorProcPtr); DOMDoc = DOMParser_getDocument(DOMParser); root = DOMDoc_getRootElem(gDOMDoc); XPathSeparator = '/'; // Get Batch information batch.id = #CtoN(DOMXPath_getAttrValue(root: 'Batch/id': *Omit)); batch.customerDivision = #CtoN(DOMXPath_getAttrValue(root: 'Batch/customerDivision':*Omit)); batch.customerSubDivision = #CtoN(DOMXPath_getAttrValue(root: 'Batch/customerSubDivision': *Omit)); batch.customerId = #CtoN(DOMXPath_getAttrValue(root: 'Batch/customerId': *Omit)); or mine? c eval DOMParser = c DOMParser_init( c pSourceType: c pSourceString: c pValidate: c 37: c pErrorProcPtr) c eval DOMDoc = DOMParser_getDocument(DOMParser) c eval root = DOMDoc_getRootElem(gDOMDoc) c eval XPathSeparator = '/' c* // Get Batch information c eval batch.id = c #CtoN(DOMXPath_getAttrValue( c root: c 'Batch/id': c *Omit)) c eval batch.customerDivision = c #CtoN(DOMXPath_getAttrValue( c root: c 'Batch/customerDivision': c *Omit)) c eval batch.customerSubDivision = c #CtoN(DOMXPath_getAttrValue( c root: c 'Batch/customerSubDivision': c *Omit)) c eval batch.customerId = c #CtoN(DOMXPath_getAttrValue( c root: c 'Batch/customerId': c *Omit)) I fail to see how your 'real world stuff' is any easier to read than mine. In fact, separating the parms to separate lines actually cleans it up, don't you think? would you like to try again? rick _______________________________________________ This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/rpg400-l or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.