PMD Module for Salesforce Metadata #4877
Replies: 4 comments 6 replies
-
First thing's first...I'm on the fence as to the namespace. It's going to be either:
The second option ties in with the unified salesforce namespace (see #3846.) The first, well, I'm not crazy about using a platform acronym in a namespace. It goes against my nature to be even a little opaque in that regard. I would love input on this sooner than later, as it's going to inform my first steps in creating this module. Tagging @codefriar as I think he's interested in following this. The old quote applies here: "The two hardest things in programming are cache invalidation and naming things." - ? |
Beta Was this translation helpful? Give feedback.
-
I'm assuming this will be under the
I'd not do this at the time being. Moving Apex / Visualforce to a different artifact to get them all together would be a breaking change (big no-no for non-major releases). Moreover, if we wanted to do something like this, we could use a meta-module (ie: a pom shipping |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
Hey @adangel and @jsotuyod . I'm still looking at this as a contribution. I've been busy with work, but much of that will inform me moving forward. Most importantly, I've had the opportunity to work with PMD 7 in the wild and leverage node streams in an HTML context. I'm starting to think that the way the HTML (or even VisualForce) language module is built might better reflect the nuances of Salesforce metadata. Although processing XML-as-XML is great, I find the context switching between the AST structure and the DOM method to be cumbersome compared to a unified approach. I've always leaned towards consistency, so that's where I get that from. |
Beta Was this translation helpful? Give feedback.
-
Hello all.
I've opened this discussion for feedback, ideas, and general updates. I'm working on contributing a language module for Salesforce metadata. I will primarily be working on this off-hours (weekends, etc.) but I have the time and the motivation.
The goal here is not to cover every possible type at the outset; rather, I want to start with the obvious: flows, and reports. Both have some easy hits (elements that require descriptions longer than n characters, etc.) As other types are brought into focus, they can be added later.
The structure I am proposing is as follows (this is rough as to namespaces, so bear with me):
I know there has been some chatter about a unified Salesforce namespace, but I wanted to get the ball rolling and get something out there for comment. I think we can unify everything when it seems feasible, but that unification comes at a cost: it will break existing code and there is wide adoption in that community.
Please share your thoughts, ideas, snide remarks, etc.! I'm excited to put something together. I've already hacked together some XML-based rules for a current project, so I'm comfortable working on something more permanent.
Incidentally this would put PMD on par (as it's own, standalone solution) with Autorabit's Codescan (at least as far as I can tell.)
@jsotuyod Please advise if this description needs some work.
A happy PMD user,
Justin Stroud
Beta Was this translation helpful? Give feedback.
All reactions