在寻找“实用"的命名约定. [英] In search for 'pragmatic' naming conventions.

问题描述

Hi,

我相信每个人都同意遵守某种命名约定最终会导致更好和更易于维护的软件.

I believe everyone agrees that adhering to some kind of naming conventions leads eventualy to better and more maintainabe software.

在LS中进行开发时，从实际/务实的角度来看，仅仅坚持使用c#(和VB)标准命名约定并不是很明显.

When developing in LS, it's not so obvious, from a practical/pragmatic point of view, to simply stick to the c# (and VB) standard naming conventions.

为了固定"想法，我将尝试阐述一个示例，在该示例中，偏离命名约定是有意义的，告诉我们方法参数名称应以驼色表示-案件. (例如:customerName).

In order to 'fixate' the ideas, I'll try to elaborate one example, where it make sense to deviate from the naming convention telling us that method parameter names should be in camel-case. (e.g.: customerName).

 

好，太好了！现在，假设我们正在构建一个自定义搜索屏幕(一个网格，顶部有一些用于查询的自定义文本框).在我们的示例"customerName"中，让我们坚持一个参数.

Ok, great! Now, imagine we are building a custom search screen (a grid, with on top some custom textboxes feeding the query). Let's stick to one param, in my example “customerName”.

因此，我们从一个自定义查询开始，在该查询中引入该参数.通常，我只使用设计器来指定参数，而不使用实际的where子句.默认情况下，我在预处理"查询中指定where子句 方法，它迫使我提高我的劣Linq技能:)

So, we start with a custom query, where we introduce that param. As a rule of tumb, I only use the designer for specifying the params, but not for the actual where clauses. By default, I specify where clauses in the Preprocess query method, it forces me to improve my poor Linq skills :)

因此，在遵循c#命名约定时，应将参数指定为customerName(这将导致预处理查询param→字符串customerName).

So, when sticking to c# naming conventions, the param should be specified as customerName (which results in the preprocess query param→ string customerName).

到目前为止，还不错，但是我们在这里完全忽略了一个事实，那就是出色的LS是一个以数据为中心的RAD平台，这意味着语义".尽可能多地被推向了市场(屏幕).

So far so good, but we are here completely neglecting the fact the brilliant LS is a datacentric RAD platform, meaning, among other things, that “semantics” are as much as possibe pushed to the ciient (the screens).

结果是，如果我让LS根据我的自定义查询生成搜索屏幕，我最终会在文本框上看到一个标签，用户可以在其中输入客户名称搜索标准，是客户名称".

As a result, if I let LS generate a search screen based on my custom query, I end up with a label on the textbox where the user can enter the Customer Name search criterium, being “customer Name”.

我讨厌自定义标签，而且我想让LS可以给我的所有东西都保留下来，所以…不好.

I hate customizing labels and I want to levarage everything LS can give me, so … no good.

 

我目前正在尝试以下方法是否可行:我将"CustomerNameIs"指定为查询参数(并违反C#命名约定)，并确保在屏幕上围绕我不同的自定义搜索条件， 有一种带有标签文本在哪里找到客户"的组框.这样，您将获得一个流畅的界面". (但是这次是流畅的USER界面).用户看到:

I'm currently trying out of if the following approach works: I specify as query param, “CustomerNameIs” (and kindy violate the c# naming convention) and make sure that on screen, around my different custom search criteria, there is sort of group box with label text “Find Customers Where”. By doing so, you get a “fluent interface” (but this time a fluent USER interface). The user sees:

在哪里找到客户"

客户名称是|                           |

Customer Name Is |                    |

城市是                      |

City Is                         |

...

我喜欢扔掉屏幕而不会感到痛苦.如果使用专用的搜索屏幕，我可以重新生成屏幕而无需任何标签自定义.

I like throwing away screens without pain in the hart. In case of my dedicated search screen, I can just regenerate the screen without any label customization.

总而言之，这使我进入了查询参数的命名约定.

To summarize, this brings me to my naming convention for query params.

这只是一个例子，其中某种实用主义和懒惰可能会导致某种程度的生产力提高.

This was just one example, where some kind of pragmatism and lazyness, might lead to some kind of productivity improvement.

如果您认为我太懒了，请忽略此论坛帖子. :)

If you believe I'm just too lazy, please disregard this forum post. :)

否则，最好与我们分享类似的方法".

If not it would be great to share with us, similar 'approaches'.

 

享受这一天

保罗.

 

推荐答案

这些都是有趣的主意.

These are interesting ideas.

我还在学习lightswitch，并试图确定一些命名约定的标准.

I'm still learning lightswitch also and trying to nail down some standard for naming conventions.

就像您一样，一旦我开始了解LINQ的功能，我决定在Preprocess查询中进行数据过滤:那里的可能性更多，并且我希望性能不会受到影响.

Like you, once I started to see the power of LINQ, I decided to do the filtering of data in the Preprocess query: there are much more possibilities there and I'm hoping that the performance will not be impacted.

我喜欢您对流利"界面的想法，您无需更改屏幕上的标签，并且会看到我可以使用它的程度.

I like your idea of a 'fluent' interface where you don't have to change the label on the screen and will see how far I can get with it.

我还在尝试对文件，查询和屏幕使用良好的命名约定，例如:     

I'm also experimenting with a good naming convention for files, queries, screens, for example:      

表格:

     客户

       Customers

           Customers_byLastName

            Customers_byLastName

          客户_按任何方式

            Customers_byWhatever

          产品

       Products

           Products_byDescription

            Products_byDescription

           Products_byCreationDate

            Products_byCreationDate

屏幕:

           Products_Detail

            Products_Detail

           Products_CreateNew

            Products_CreateNew

           Products_List_FilterByCategory

            Products_List_FilterByCategory

等等

令我惊讶的是，您对这些查询没有更多的回答，因为这些都是重要的问题.

I'm surprised you haven't had more responses to your query as these are important questions.

 

此致

David Corbett

David Corbett

 

 

这篇关于在寻找“实用"的命名约定.的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！