PowerShell receive 与 get 动词
我已经看到很多关于在自己的 PowerShell 函数中使用哪些动词的讨论，但我还没有看到关于使用 Receive 与 Get 的说明。它们对我来说意义大致相同，但是 Receive 应该专门用于涉及通信的情况（只需输入 Get-Verb 即可查看这）。然而，Get 属于 Common 组，所以我真的不确定该使用哪一个。
我有一个函数，基本上包装了 RESTful API 并从中获取数据（我使用服务不同方法的参数集）。现在该函数称为 Get-FooData。但是，我认为我应该将其重命名为 Receive-FooData，因为它正在进行一些通信。
我认为我想使用 Receive 的想法太直白了。我个人的感觉是 Get 听起来更好，但我认为这只是因为我习惯使用它。你有什么想法？
I've seen quite a few discussions on which verbs to use in your own PowerShell functions, but I haven't seen a clarification on using Receive vs. Get. They mean roughly the same thing to me, but Receive is supposed to be used specifically in situations involving communications (just type Get-Verb to see this). Get, however, is in the Common group, so I'm really not sure which one to use.
I have a function that basically wraps a RESTful API and gets data from it (I use parameter sets for the different methods of the service). Right now the function is called Get-FooData. However, I'm thinking that I should possibly rename it to Receive-FooData since it is doing some communication.
I think I'm being too literal here in wanting to use Receive. My personal feeling is that Get sounds better, but I think that's just because I'm used to using it. What are your thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
虽然我对 PowerShell 的精通只是业余水平，但对我来说，“get”意味着一种更有力和更负责的代码类型。这意味着我的代码将启动该操作，其他软件将谦虚地响应我的请求。
“接收”听起来更温顺，意味着其他软件真正负责。因此，如果其他软件每分钟输出一次温度，我可能会使用“接收”。我将接收数据，但即使我不在那里接收数据，其他软件也会执行其操作。
“Get”更短，大多数时候我喜欢感觉是我的代码负责。与 Get 一起去。
Although I'm proficient at PowerShell at only the amateur level, for me, "get" implies a much more forceful and in-charge type of code. Meaning my code is going to initiate the action, and the other software will humbly respond to my request.
"Receive" sounds more docile, meaning the other software is really in charge. So I might use Receive if the other software was for example putting out temperatures once a minute. I'm going to receive the data, but the other software is doing its thing even if I wasn't there to receive it.
"Get" is shorter and most of the time I like to feel like my code is in charge. Go with Get.
使用名词来决定。如果您的名词是要检索的对象，则使用“GET”。如果名词是检索某些内容的机制，则使用“RECEIVE”。
例如
GET-BOOK -via REST
RECEIVE-REST -object book
Use the noun to decide. If your noun is the object that is being retrieved then use "GET". If the noun is the mechanism by which you retrieve something, then use "RECEIVE".
e.g.
GET-BOOK -via REST
RECEIVE-REST -object book
这是一个有趣的设计问题，我曾经多次思考过这个选择。根据这些指南：
Microsoft 命令行标准
以及我的感觉，如果我还设计了一对/卫星通信命令
Send-X、Connect-X、这种方法提高了可发现性：如果我看到 Receive-X，那么即使不阅读手册，我也期望存在其他命令。从某种意义上说，这对于本机 PowerShell 命令
Receive-Job来说是正确的：我们不能只调用它（与Get-Item、Get-Process不同）等），我们必须启动一些可以在之后接收数据的东西，即首先我们调用Start-Job。但就我个人而言，我会以不同的方式称呼它：Get-JobResult或类似的名称；对我来说，这个名称不会那么令人困惑：这是我们获得的作业结果，而不是作业实例，并且没有像Send-Job这样的其他卫星命令。名称Receive-Job仍可用于将来可能更合适的用途。在大多数情况下，我会选择
Get。但是，如果您确实希望用户停下来思考一下为什么 X 被称为Receive，而不是Get，并且这是有原因的，那么Receive可能合适。总而言之，我从未在 cmdlet/脚本/函数名称中真正使用过动词
Receive：某些东西始终不足以做出此选择。This is an interesting design question and I used to think on this choice a few times. According to these guidelines:
Microsoft Command Line Standard
and my feeling, too, I would use
Receive-Xname in cases when I also design one of the pair/satellite communication commandsSend-X,Connect-X, etc. This approach improves discoverability: if I see theReceive-Xthen even without reading manuals I also expect additional commands to exist.In some sense this is true for the native PowerShell command
Receive-Job: we cannot just call it (unlikeGet-Item,Get-Process, etc.), we have to initiate something which data can be received afterwards, namely at first we call theStart-Job. But personally, I would call it differently:Get-JobResultor something like that; to me this name would be less confusing: it's the job results that we get, not the job instances, and there are no other satellite commands likeSend-Job. The nameReceive-Jobwould be still available for something perhaps more adequate in the future.I would go with
Getin most cases. But if you actually really want a user to stop and think for a moment of why X is calledReceive, notGet, and there are reasons for that thenReceivemight be suitable.All in all, I have never really used the verb
Receivein my cmdlet/script/function names: something always was not enough for making this choice.