Code gets read more often than it gets written, so how it gets laid out on the screen is a critical component of maintainability. When a project involves more than one person checking in code, it gets even more important.
So, here’s a peek inside the MarkLogic Engineering team’s process — our set of agreed-upon guidelines for formatting XQuery code. It’s arranged in a laws-of-robotics sequence with the cardinal rule first. Following rules fill out the details, but can’t override the earlier rules.
It’s my hope that this is a useful resource for XQuery programmers everywhere. The intent of this guide is to provide a few key rules for sensible application, rather than exhaustive enumeration.
Thou shalt not mix tabs and spaces. The entire project must exclusively use spaces (four) for indentation, except for third party libraries (e.g. XSLTforms, YUI).
Structure function signatures using the following example:
declare function my:function( $a as xs:string, $b as element(my:options) ) as empty-sequence() { (: body of function :) };
Use common sense and make code readable on the screen unless it would conflict with rule 0 or 1.
If editing existing code, adopt a style to fit in with what’s already there, unless it would conflict with rules 0, 1 or 2.
If/Then/Else or For/Let/Where/Order by/Return statements should either fit on a single line, or else have the aforementioned keywords left aligned, unless it would conflict with rules 0, 1, 2 or 3.
Examples:
(: one line if/then/else :) if ($condition) then $action else ()
(: multiple line if/then/else :) if ($condition) then xdmp:log("If we kept this on one line, it would be unreadable") else xdmp:log("This is a very long action, don't want it to scroll")
(: chained if/then/else :) if ($condition) then xdmp:log("If we kept this on one line, it would be unreadable") else if ($condition2) then xdmp:log("This is a very long action, don't want it to scroll") else for $i in (1,2,3) return concat("line ",$i)
(: flwor :) let $a := "alpha" for $i in (1 to 50) where $i mod 2 eq 1 return concat($a,$i)
(: flwor :) let $a := "alpha" for $i in (1 to 50) let $x := $i mod 2 where $x eq 1 return concat($a,$i)
(: flowr with subordinate flwor :) let $a := "alpha" let $x := for $i in (1 to 50) where $i mod 2 eq 1 return concat($a,$i) return $x
Use a consistent amount of indentation as the rest of the project (four spaces), unless it would conflict with rules 0, 1, 2, 3 or 4.
Use sparing comments to indicate the intent of blocks of code; if the project uses XQDoc-style comments, do this also, unless it would conflict with rules 0, 1, 2, 3, 4 or 5.
Use short, but meaningful, variable and function names. Use a default prefix instead of fn: and always use a prefix for defined functions, unless it would conflict with rules 0, 1, 2, 3, 4, 5 or 6.
View all posts from Micah Dubinko on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Let our experts teach you how to use Sitefinity's best-in-class features to deliver compelling digital experiences.
Learn MoreSubscribe to get all the news, info and tutorials you need to build better business apps and sites
Progress collects the Personal Information set out in our Privacy Policy and the Supplemental Privacy notice for residents of California and other US States and uses it for the purposes stated in that policy.
You can also ask us not to share your Personal Information to third parties here: Do Not Sell or Share My Info
We see that you have already chosen to receive marketing materials from us. If you wish to change this at any time you may do so by clicking here.
Thank you for your continued interest in Progress. Based on either your previous activity on our websites or our ongoing relationship, we will keep you updated on our products, solutions, services, company news and events. If you decide that you want to be removed from our mailing lists at any time, you can change your contact preferences by clicking here.