xuxiaowei-com-cn commented on PR #8190:
URL: https://github.com/apache/incubator-seata/pull/8190#issuecomment-5146454446
> Should variable naming conventions be kept consistent？
/cc @funky-eyes
## 中文
感谢您的细致 review，这对我们非常有帮助。关于命名一致性的问题，我的想法如下：
---
**首先，我完全认同“保持一致性”是重要的设计原则**，但在具体实现时，也需要考虑使用场景的差异。经过权衡，我倾向于继续使用
`nodeVersion`（而非 `node.version`），主要基于以下三点考虑：
1. **与 `frontend-maven-plugin` 自身的属性命名习惯保持一致**
该插件预定义的覆盖属性（如 `nodeDownloadRoot`、`npmDownloadRoot`、`yarnDownloadRoot`
等）均采用**驼峰式**命名，且无点分隔。`nodeVersion` 作为其直接对应的版本覆盖参数，沿用这一风格可以让用户更自然地通过
`-DnodeVersion=...` 进行覆盖，无需额外记忆“点”或“横线”的变体。
2. **与插件文档和社区常见用法对齐**
`frontend-maven-plugin` 的官方文档及大量开源项目示例中，版本覆盖通常写作 `nodeVersion`（例如
`<nodeVersion>${nodeVersion}</nodeVersion>` 并配合
`-DnodeVersion`），这是该插件的“事实标准”。沿用这一约定可以降低新用户的学习成本。
3. **保持与本次修改前硬编码文本的一致性**
原始 POM 中硬写的是 `v19.5.0`，本次改动只是将其抽取为属性，若属性名为 `nodeVersion`，则表达式
`${nodeVersion}` 与原先的语义最贴近，更易于代码审阅者理解这是一次“原地替换”而非引入新概念。
---
当然，我也理解您的顾虑——项目内其他版本属性（如 `protobuf.version`、`grpc.version`）确实采用了 `点分隔`
的风格。这确实存在风格不统一的问题。但在处理**插件专用属性**时，我倾向于优先遵循该插件自身的生态惯例，而非强行套用项目的通用规则，因为这类属性通常只在特定插件作用域内生效，影响范围有限。
如果您认为从项目全局规范角度出发，应强制统一为 `node.version`，我也愿意调整。不过从实用性和用户友好性出发，我个人更推荐保留
`nodeVersion`。期待您的进一步意见，我们可以继续讨论并达成共识。
再次感谢您的宝贵时间！
## En
Here’s an English translation of the revised reply, suitable for responding
to the reviewer on GitHub:
---
Thank you for your careful review—it is very helpful to us. Regarding the
consistency of naming, here are my thoughts:
**First, I fully agree that "keeping consistency" is an important design
principle**, but when it comes to specific implementations, we also need to
consider differences in usage contexts. After weighing the options, I tend to
stick with `nodeVersion` (rather than `node.version`), based on the following
three points:
1. **It aligns with the naming conventions of the `frontend-maven-plugin`
itself.**
The plugin’s predefined override properties—such as `nodeDownloadRoot`,
`npmDownloadRoot`, `yarnDownloadRoot`, etc.—all use **camelCase** without dots.
Since `nodeVersion` is the direct counterpart for the Node.js version override,
following this style makes it more natural for users to override via
`-DnodeVersion=...`, without needing to remember a dotted or dashed variant.
2. **It matches the plugin’s documentation and common community practice.**
The official documentation of `frontend-maven-plugin` and many
open‑source examples typically use `nodeVersion` (e.g.,
`<nodeVersion>${nodeVersion}</nodeVersion>` with `-DnodeVersion`). This has
become the *de facto* standard for this plugin. Adopting this convention
reduces the learning curve for new contributors.
3. **It stays consistent with the original hardcoded value before this
change.**
The original POM hardcoded `v19.5.0`. By simply extracting it to a
property named `nodeVersion`, the expression `${nodeVersion}` remains
semantically closest to the original, making it easier for reviewers to
recognize that this is a straightforward replacement rather than introducing a
new concept.
---
Of course, I understand your concern—other version properties in the
project, such as `protobuf.version` and `grpc.version`, do follow the dotted
style. This does introduce some inconsistency at the project level. However,
for **plugin‑specific properties**, I prefer to follow the plugin’s own
ecosystem conventions rather than force‑fit the project’s general rules,
because such properties typically only affect a specific plugin scope and have
limited impact.
If you believe that from a global project‑wide perspective we should enforce
`node.version` for uniformity, I am happy to adjust. However, from a practical
and user‑friendliness standpoint, I personally recommend keeping `nodeVersion`.
I look forward to your further thoughts—we can continue the discussion and
reach a consensus.
Thank you again for your valuable time!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
