仅仅为了更改名称而包装 PHP 库函数是否可以接受?

发布于 2024-08-27 02:58:21 字数 404 浏览 5 评论 0原文

今年夏天我将启动一个相当大的 PHP 应用程序,我将是该应用程序的唯一开发人员(因此,除了我自己的编码约定外,我没有任何需要遵守的编码约定)。

在我看来,PHP 5.3 是一种不错的语言,尽管命名空间标记很愚蠢。但一直困扰我的一件事是标准库及其缺乏命名约定。

所以我很好奇,将一些最常见的标准库函数包装在我自己的函数/类中以使名称更好一点会是非常糟糕的做法吗?我想在某些情况下它也可以添加或修改一些功能,尽管目前我没有任何示例(我想我会找到方法使它们面向对象或在我工作时使它们的工作方式略有不同)。

如果您看到一名 PHP 开发人员这样做,您会认为“伙计,这是一个劣质的开发人员吗?”

此外,我对 PHP 是否/如何优化了解不多(或任何事情),而且我知道通常 PHP 性能并不重要。但是这样做会对我的应用程序的性能产生显着影响吗?

I'm going to be starting a fairly large PHP application this summer, on which I'll be the sole developer (so I don't have any coding conventions to conform to aside from my own).

PHP 5.3 is a decent language IMO, despite the stupid namespace token. But one thing that has always bothered me about it is the standard library and its lack of a naming convention.

So I'm curious, would it be seriously bad practice to wrap some of the most common standard library functions in my own functions/classes to make the names a little better? I suppose it could also add or modify some functionality in some cases, although at the moment I don't have any examples (I figure I will find ways to make them OO or make them work a little differently while I am working).

If you saw a PHP developer do this, would you think "Man, this is one shoddy developer?"

Additionally, I don't know much (or anything) about if/how PHP is optimized, and I know that usually PHP performace doesn't matter. But would doing something like this have a noticeable impact on the performance of my application?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

情绪少女 2024-09-03 02:58:21

您现在可能是唯一的开发人员,但其他人会选择此代码吗?如果是这样,如果您只是简单地包装调用,那么您确实应该主要坚持使用标准库名称。

我曾经使用过作者封装了这样的调用的代码,这确实损害了快速理解代码的能力

如果您看到 PHP 开发人员这样做,您会认为“伙计,这是一个劣质的开发人员吗?”

好吧,不……但我会想“该死……我必须学习这家伙的新命名标准,尽管是善意的,但这会花费我时间”

You might be the only developer now but will someone else ever pick up this code? If so you really should stick mainly to the standard library names if you're doing nothing more than simply wrapping the call.

I've worked with code where the author has wrapped calls like this and it really does harm the ability to quickly understand the code

If you saw a PHP developer do this, would you think "Man, this is one shoddy developer?"

Well no...but I'd think "Damn...I've got to learn this guys new naming standard which although well-intentioned will take me time"

书间行客 2024-09-03 02:58:21

我假设您不仅指的是命名约定,还指的是函数(needle,haystack)和函数(haystack,needle)参数顺序的快乐混合。

我完全可以理解为了自卫而围绕这些构建理智的包装器的愿望。不过,我仍然不愿意这样做,只是因为它为您的项目添加了一个专有层,这将使其他人更难以理解。每个人都知道 array_push 的作用,但是 MyArrayFunctions::push 人们可能需要查找,甚至深入了解它的作用。

我倾向于坚持这些标准,尽管在这种情况下它们确实很糟糕。另外,有了一个像样的 IDE,可以在键入时查找函数和参数,问题已经大大减少。

另一方面,我真的看不出有什么坏处,比如说,一个静态类 Array 带来了所有 push()pop()< /code>、array_this()array_that() 合并为一种标准形式。我想说这取决于你,真的。

I assume you are referring not only to naming conventions, but also to the merry mixture of function (needle, haystack) and function(haystack, needle) parameter orders.

I can totally understand the desire to build sane wrappers around these in self-defense. I still rather wouldn't do it, though, simply because it adds a proprietary layer to your project that will make it harder to understand for others. Everybody knows what array_push does, but MyArrayFunctions::push one may have to look up, or even look into to find out what it does.

I tend to stick with the standards, even though they're admittedly crappy in this case. Plus, with a decent IDE that can look up functions and parameters as you type, the problem is already much reduced.

On the other hand, I can't really see any harm in, say, a static class Array that brings all the push(), pop(), array_this() and array_that() into one standard form. I'd say it's up to you, really.

难以启齿的温柔 2024-09-03 02:58:21

简单的包装器不会影响您的性能,但这可能会让该项目的任何未来开发人员感到困惑。作为一名 PHP 程序员,您会慢慢地开始期待奇怪的命名约定。

如果您要添加任何功能,最好保持一致的约定。我使用过一个 PHP 静态类,它包装了本机数组函数(并添加了新函数)。始终具有相同的参数位置非常方便。

Simple wrappers wont hit your performance, but this might confuse any future developers on the project. As a PHP programmer you slowly come to expect the weird naming conventions.

If you are adding any functionality its great to have consistent conventions. I have worked with a PHP static class that did wrap the native array functions (and add new ones). It was quite convenient to always have the same argument placements.

污味仙女 2024-09-03 02:58:21

在我看来,例如数组的 OOP 实现是可以的,您将包装它们并部分修改功能,但是只是重命名函数和调整我不喜欢的参数。

如果您确实需要这样做,请确保使用 phpdoc 对其进行注释,以便人们可以在其 IDE 的自动完成功能中看到正确的语法。

In my opinion OOP implementations of for example an array are okay, you will wrap them and partially modify functionality, however just renaming functions and shuffling arguments I don't like.

If you really need to do it make sure you comment it with phpdoc so people can see the correct syntax in the autocomplete of their IDE.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文