开放式问题 - 充分利用所有功能，还是有选择性？ [英] Open question - leverage all features liberally, or be selective?

问题描述

在最近的一个帖子中，RKC（正确地，我相信），在Property Let过程中使用

多个参数来传递维度

参数虽然它有效，但如果您不知道Property Let / Get

语法的复杂性，那么

代码的工作原理并不明显。 。同样，我不喜欢（以及最小化使用的代码）VB / VBA

语法通过引用函数名来返回值，就好像它是因为它是b / b $ ba变量因为这与recusrive

函数调用的语法太相似了。我必须做一些实验，以确定在函数

名称之后的所有情况下是否发生了什么

（David Fenton指出没有这里技术含糊不清，

但我认为这是另一个需要神秘知识来阅读一些

代码的情况，它会干扰我的重构实践。）


所以，虽然系统的所有功能（在这种情况下是Access / VBA）都是为了增加一些价值，但也许最好提出开发

策略和习惯用法仅使用某些子集的功能

某些明确的方法来结束更简单，更容易的代码
维持。


好​​吧，我Aculpa - 这不是一个问题，那是一个肥皂盒。仍然，意见？


我想对面的argumnent将是，当系统的一个功能

或语言提供你需要的东西时，为什么不利用它现在

而不是花时间思考一个代码或者在程序中添加额外的

代码行（比如实际上对一个返回变量进行维数）
添加返回类型规范的重复）或跳过维度

属性让代价使用函数语法而不是更多

明显的数组语法在索引列表属性中设置一个值。


我猜对方的说法听起来也不错 - 嗯？


- Steve Jorgensen

In a recent thread, RKC (correctly, I believe), took issue with my use of
multiple parameters in a Property Let procedure to pass dimensional
arguments on the basis that, although it works, it''s not obvious how the
code works if you don''t know the intricacies of the Property Let/Get
syntax. Likewise, I dislike (and code to minimize the use of) the VB/VBA
syntax of returning a value by referring to the function name as if it were
a variable because this is too similar to the syntax for a recusrive
function call. I had to do some experiments to find out for sure what
happens in all cases with or without the parentheses after the function
name (David Fenton points out that there is no technical ambiguity here,
but I think this is another case of needing arcane knowledge to read some
code, and it interferes with my refactoring practices).

So, although all the features of a system (Access/VBA in this case) were
put there to add some value, perhaps it is best to come up with development
strategies and idioms that make use of only certain subsets of features in
certain clear ways to end up with code that''s simpler and easier to
maintain.

OK, Me Aculpa - that''s not a question, that''s a soap box. Still, opinions?

I guess the opposing argumnent would be that, when a feature of the system
or language provides something you need, why not leverage that right now
rather than take time thinking of a code-around or adding extra lines of
code to a procedure (such as dimentioning a return variable which actually
adds duplication of the return type spec) or skipping a dimensional
property Let at the expense of using a function syntax rather than the more
obvious array syntax to set a value in an indexed list property.

I guess the opposing argument sounds pretty good, too - hmm?

- Steve Jorgensen

推荐答案

no **** @ nospam.nosp am（Steve Jorgensen）在

写道< td ******************************* *@4ax.com>：

no****@nospam.nospam (Steve Jorgensen) wrote in
<td********************************@4ax.com>:

（David Fenton指出，这里没有任何技术歧义，但我认为这是另一个需要神秘知识来阅读一些代码的案例，它会影响我的重构实践）。

(David Fenton points out that there is no technical ambiguity
here, but I think this is another case of needing arcane knowledge
to read some code, and it interferes with my refactoring
practices).

其他帖子已经从我的新闻服务器上过期了，所以，在Google上读完了你的答案后，我会在这里回答这一点：


我没有看到一个该死的东西是奥术。它是

方式的功能，无论是用户定义的还是内置的。如果你不知道这是怎么回事，那么你真的不熟悉VBA，而且你的b $ b你的编码可能比任何东西都要糟糕得多

你的建议会解决。


了解特定语言的工作原理并不是我认为的奥术。知识 - 这是编程语言流利的基础知识。对于初级程序员来说，你的观点可能非常有意义，但在某个层面上，但是

我不确定它会对它做什么帮助他们了解

VBA实际上是如何运作的。因此，我没有看到它的价值。


但是，我们都有自己的编码风格。


-

David W. Fenton http://www.bway.net/ ~dfenton

dfenton at bway dot net http： //www.bway.net/~dfassoc

On Sun，2003年9月14日21:29:30 GMT， dX ******** @ bway.net （David W. Fenton）

写道：

On Sun, 14 Sep 2003 21:29:30 GMT, dX********@bway.net (David W. Fenton)
wrote:

no **** @ nospam.nospam（Steve Jorgensen）在
< td *******************写道*************@4ax.com>：

no****@nospam.nospam (Steve Jorgensen) wrote in
<td********************************@4ax.com>:

（David Fenton指出这里没有技术歧义
，但我认为这是另一个需要神秘知识来阅读一些代码的情况，它会干扰我的重构实践）。
那个o我的新闻服务器已经过期了，所以，在Google上阅读了你的答案之后，我会在这里回答这一点：

我没有看到一个该死的东西这就是奥术。这是函数工作的方式，无论是用户定义的还是内置的。如果你不知道它是如何工作的，那么你对VBA的熟练程度并不高，而且你的编码可能比你的任何事情都要糟糕得多
你的建议会解决。

(David Fenton points out that there is no technical ambiguity
here, but I think this is another case of needing arcane knowledge
to read some code, and it interferes with my refactoring
practices).
That other thread has expired from my news server, so, having read
your answer on Google, I''ll respond to this point here:

I don''t see a damned thing about this that is "arcane." It''s the
way functions work, whether user-defined or built-in. If you don''t
know how that works, then you really aren''t skilled in VBA, and you
probably have far worse problems with your coding than anything
your suggestions would address.

嗯，我认为自己非常擅长VB / VBA，尽管我的知识中有一些长期存在的差距。暴露（选择是VBA，

函数 - doh！）。不过，我不知道函数中对

函数名称的不同引用会如何表现。这是因为我早期选择了不使用该功能的样式进行编码，因为我觉得它很难看。


这些天我瞄准的是代码清楚，而不仅仅是说明如果你对我写的语言很精明，那么
会说清楚。我可以阅读

关于Java的书籍，看看一些代码示例看起来像是他们的b $ b $是由Java专家编写的，但它们是不可思议的，其他例子

做同样具有挑战性的事情，几乎任何人都可以阅读

，完全没有Java知识。我会争辩说，那些没有特殊知识的人更容易阅读b
更容易维护，即使是那些精通语言的人也很容易。非常清晰的代码也有点像一个干净的

办公室 - 工作更愉快，更容易生产

with。

关于特定语言如何运作的知识不是我认为奥术的东西。知识 - 这只是
的基础知识

奥术可能夸大了这一点，但我仍然认为代码很明显

可能更可取代码不仅仅是因为这个原因。
流利的编程语言。对某些程度的初级程序员来说，你的观点可能非常有意义，但是我不确定它能帮助他们理解如何做任何事情
VBA确实有效。因此，我没有看到它的价值。

但是，我们都有自己的编码风格。

Well, I consider myself very good at VB/VBA in spite of some long standing
gaps in my knowledge that have recently been exposed (Choose is a VBA,
function - doh!). Still, I did not know how different references to the
function name from within the function would behave. This is because I
chose early on not to code in a style that would use that feature much
because I thought it was ugly.

What I''m aimimg for, these days, is code that speaks clearly, not just that
speaks clearly if you''re savvy with the language I wrote it in. I can read
books on Java, for instance, and see some code examples that look like they
were written by Java experts, but they''re inscrutable, and other examples
doing equally challenging things that can be read by pretty much anyone
with no Java knowledge at all. I would argue that the one that''s easier to
read with no special knowledge is easier to maintain even by someone well
versed in the language. Very clear code is also kind of like a clean
office - it''s just more pleasant to work in and easier to be productive
with.
Knowledge of how a particular language works is not something that
I consider "arcane" knowledge -- it''s just the basics of being
Arcane may be overstating the point, but I still think code that is obvious
may be preferable to code that is not for that reason alone.
fluent in the programming language. You''re point of view might very
well make sense for beginning programmers, at a certain level, but
I''m not sure that it would do anything to help them understand how
VBA actually works. Because of that, I don''t see the value.

But, we all have our own coding styles.

嗯，这个可能只是我对我以前真正神秘的代码的强烈抵制

养成了写作的习惯。我会随着时间的推移进行优化，尝试留下钩子

用于可能需要发生的一切，等等。我正在摆动钟摆

回到另一个方向，优先考虑清晰度和简单性，仅在存在性能问题时优化

，并在我发现需要时优化什么是慢，

添加功能，当时需要重构为
，使用长名称，使用描述性临时

变量进行部分计算等。


所以也许，我现在想要明确和简单了我的目标

当我谈到简单地避免使用不完全显而易见的功能时，我就是b $ b 我还不相信。

Well, this could all just be my backlash to the truly arcane code I used to
be in the habit of writing. I would optimize as I went, try to leave hooks
for everything that might need to happen, etc. I''m swinging the pendulum
back the other way, and prioritizing clarity and simplicity, optimizing
only when there is a performance issue, and optimizing just what''s slow,
adding functionality when I find that it''s needed, and refactoring as
necessary at the time, using long names, using discriptive temporary
variables for parts of calculations, etc.

So Perhaps, I am going overboard on aiming for clarity and simplicity now
when I speak of simply avoiding the use of functionality that is not
completely obvious, but I''m not yet convinced.

[编者注：Steve Jorgensen是Access Morons的特许会员。

这是他长期运行的愚蠢系列中的第233号。]

" Steve Jorgensen" <无**** @ nospam.nospam>在消息中写道

news：td ******************************** @ 4ax.com ...

[Editor''s Note: "Steve Jorgensen" is a charter member of Access Morons.
This is Number 233 in his long-running moronic series.]
"Steve Jorgensen" <no****@nospam.nospam> wrote in message
news:td********************************@4ax.com...

在最近的一个帖子中，RKC（正确地，我相信），在Property Let过程中使用
多个参数来传递维度
参数时遇到了问题虽然它有效，但如果您不知道Property Let / Get
语法的复杂性，那么
代码的工作原理并不明显。同样，我不喜欢（以及最小化使用的代码）VB / VBA
语法通过引用函数名来返回值，好像它是
是一个变量，因为它太类似于语法用于recusrive
函数调用。我不得不做一些实验，以确定在功能名称之后有或没有括号的所有情况下发生了什么（David Fenton指出这里没有技术歧义，
但我认为这是另一个需要神秘知识来阅读一些代码的情况，它会干扰我的重构实践。）

所以，虽然系统的所有功能（Access / VBA）在这种情况下）被放在那里以增加一些价值，也许最好提出
开发策略和习惯用法，只使用某些特定的子集以某些明确的方式最终得到的代码更简单，更容易维护。

好的，我Aculpa - 这不是一个问题，那是一个肥皂盒。还有，
意见？
我想反对的意思是，当系统的一个功能或语言提供你需要的东西时，为什么不立即利用它呢
而不是花时间思考代码或向程序添加额外的代码行（例如对返回变量进行维数，实际上添加返回类型规范的重复）或跳过维度
property以牺牲使用函数语法而不是
更明显的数组语法来设置索引列表属性中的值。

我认为反对的论点听起来也不错 - 嗯？

- Steve Jorgensen

In a recent thread, RKC (correctly, I believe), took issue with my use of
multiple parameters in a Property Let procedure to pass dimensional
arguments on the basis that, although it works, it''s not obvious how the
code works if you don''t know the intricacies of the Property Let/Get
syntax. Likewise, I dislike (and code to minimize the use of) the VB/VBA
syntax of returning a value by referring to the function name as if it were a variable because this is too similar to the syntax for a recusrive
function call. I had to do some experiments to find out for sure what
happens in all cases with or without the parentheses after the function
name (David Fenton points out that there is no technical ambiguity here,
but I think this is another case of needing arcane knowledge to read some
code, and it interferes with my refactoring practices).

So, although all the features of a system (Access/VBA in this case) were
put there to add some value, perhaps it is best to come up with development strategies and idioms that make use of only certain subsets of features in
certain clear ways to end up with code that''s simpler and easier to
maintain.

OK, Me Aculpa - that''s not a question, that''s a soap box. Still, opinions?
I guess the opposing argumnent would be that, when a feature of the system
or language provides something you need, why not leverage that right now
rather than take time thinking of a code-around or adding extra lines of
code to a procedure (such as dimentioning a return variable which actually
adds duplication of the return type spec) or skipping a dimensional
property Let at the expense of using a function syntax rather than the more obvious array syntax to set a value in an indexed list property.

I guess the opposing argument sounds pretty good, too - hmm?

- Steve Jorgensen

这篇关于开放式问题 - 充分利用所有功能，还是有选择性？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！