A step-by-step guide to writing unmaintainable PHP code

With the unemployment rate getting higher and higher, many people realize how important it is to keep their jobs. So what’s a good way to keep your job and make yourself irreplaceable? The simple fact is that as long as no one can maintain your code, you have successfully kept your job. Writing unmaintainable code is a special skill, but strangely, seems to come naturally to some developers. But for the remaining developers out there, here are some tips and hints to get you started writing unmaintainable code.

The first thing to do

The first step is to find a job. You should look for the right company where you can flourish and realize your untenable potential. You don’t necessarily need to be the PHP guru at your company, and if you are, that’s even better. When looking for a job, if the job description mentions migrating to PHP from another program (so you know you'll be the one calling the shots), you can also search for misleading jobs that require 10 years of experience with PHP5, plus proficiency in FrontPage and Netscape. Composer.

Once you get this once-in-a-lifetime opportunity, take steps from day one. Speak up at meetings and make your voice heard. Boldly talk about object-oriented architecture design, enterprises, reform plans, and how to make good enough better. Of course, you must also make corresponding commitments. Make sure everyone consults you on important coding steps.

Unmaintainable core

Inspired by the excellent article "Writing unmaintainable code" (must be read by those who want to keep their jobs), here is what you need Two important concepts to master and master:

1. You should make it impossible for others to easily modify anything without breaking something else.

   Maintainers don't have time to understand your code. Maintainable code means being able to quickly locate a specific part in a mountain of code, being able to quickly understand how it works and change it without breaking something. You can't do this. Don't make it easy for others to search for something or find it where they expect it to be.

2. Your code cannot "look" unmaintainable (because others will suspect it), it must "be" unmaintainable.

   The code should look normal to maintainers, but surprise them when they least expect it.

Best Practices

1. No code conventions. There are endless diatribes about encoding and naming conventions. This should never happen in your excellent organization. You have a cool project to work on, and you can’t spend countless hours debating whether to use tabs or spaces. Besides, agreements are limitations. If a new person joins the company and he is not used to your agreement, he will be miserable. An unhappy programmer is an ineffective programmer. Explain to anyone who asks you. Let everyone write code in their own preferred style. As for your own code - transform your convention. Mondays are named in camelCase, Tuesdays are named in all_lowercase, Fridays are mixed, and Hungarian notation is used on each February 29th.

2. Do not write comments. Your code is beautiful, it does not need comments. If someone doesn't understand your code, then there's a good chance they're not that good a programmer. If, if possible, you are forced to write a comment, then just write it in an exaggerated way. Describe the most obvious and least important code in detail, skipping the rest.

3. Use Notepad to encode. Or use another editor that does not display code indentation. Making others suffer and eventually leave the team. This way you don't have to listen to their complaints all the time. If someone asks you why you use Notepad, be prepared to explain: Because it comes from Windows (the only operating system for creative programmers today), requires no required training, and costs nothing. I'm sure you can find references online that you can use any program, even Word, to code your web pages, but only Notepad is the real authority, after all, the only person your company employs is you.

4. Reject unit test. Explain to anyone who questions you that you were hired to write high-quality, bug-free code (so no testing required). Why would anyone in their right mind take the time to write trivial tests to prove that the code works correctly? Some things in life are like - the sky is blue, the sun rises in the east, your code works, so thank you very much. Continue (just like the comments, if forced to take the test, be prepared to test the obvious and skip the rest)
   

5. Not using a template engine . Template engines can help you distinguish between the business logic layer and the presentation layer. It ensures the maintainability of the code so you can't follow this rule. Rasmus Lerdorf, the father of PHP, said: "PHP is a template engine." Even if you have to use a template engine, find ways to abuse it, such as putting some business code in the template, or carefully mixing HTML (and CSS and JavaScript) code in the database access layer.
   In general, try to mix your PHP, HTML, CSS and JavaScript code neatly together on the same line of code whenever possible. Create JavaScript and HTML code with inline styles within PHP code. If anyone asks, tell them this pattern is called "encapsulation" and that you take full responsibility for your code.

6. version control. While this is difficult to avoid, it's worth trying to free yourself from any form or version control. You can demonstrate during discussions that this improves communication among team members, rather than relying on cold-blooded version control software. If you don't convince anyone, don't despair. You don’t need to commit all when submitting. Keep some of your own code locally. These small but fatal pieces of code will break the project if someone other than you tries to build and deploy it. If you get caught, just argue that the code is not yet suitable for presentation. After all, you submitted high-quality code and excellent solutions that can educate the junior team. These little boys and girls will be looking up to you with anticipation!

7. Build a framework. Then you inevitably become the architect, and your authority is unquestionable. This way you can add secret conventions (most of which are sometimes contradictory, of course) that even the most experienced maintainers won't detect. Your framework will take care of everything, no one will have to bother understanding it, and everyone will be happy because you alone make development easier and increase the productivity of the entire company. Don't release your framework as open source, because a) the framework is the property of the company and the company has invested a lot of money in it, and b) the open source community will laugh at you, and it will be the end of your bravado.

Naming related

Your variable name should be mysterious, preferably only one letter. This way no one can find what they need through a simple search.

Class names and methods are best defined with one letter. If you really want to define a normal name, then use it all the time - remember, the best way to hide information is to use it frequently. When reusing the same name (known as "object-oriented programming"), it will help improve the readability of your code and keep teammates in your code if you place the parentheses and curly braces on a new line. When looking for anything, you have to brush up on regular expressions. Consider this:

  $noodles = 1;
    class
    noodles
    {
        var $noodles = 2;
        function
            noodles            ()
        {
            $noodles['noodles'] = 'noodles';
        }
    }
    function
        noodles() {
            return new noodles;
        }
    $noodles = noodles();
    var_dump($noodles);

You can also use fancy character sets to name variables. The Cyrillic alphabet is perfect because some letters look like the Roman alphabet but are not (all of them: xopekacMEBCTAKXOPH). Then the following output is:

   $alert = 1;
    $аlert = 2;
    echo $alert;

If the second alert starts with the Cyrillic letter "a", then it is not possible!

引用相关

即使你非常正常的定义来一些东西，但并不意味着你不能以有趣的方式来使用它。主要的武器有：

• eval()

• 可变变量

• 可变类，比如 $strudels = "noodles"; $noo = new $strudels;

• call_user_func()

基本上任何将代码视为字符串的语言结构都是你的好朋友。

   // calling abc();
    $z = 'A';
    call_user_func($z .'bC');

大写

字母例子，函数方法名不区分大小写，滥用这个特点。

function abc(){
    echo "abc";}AbC();

另一方面，数组的健（key） 对大小写敏感，也滥用这个特点。

$a['UseConvetionsOnlyTobreakThem'] = 1;if (isset($a['UseConvetionsOnlyToBreakThem'])) {
    // ?? 大写 B !!1!}

重写

在不期望的情况下重写全局变量，尤其是超全局变量。尽早重写 $_GET 数组中的属性，多次重写，$_POST 亦是如此。在 $_REQUEST 上做一些不起眼的重写作为点缀。如果是在 WTF-ed 上，你可以解释是在防止用户输入的 XSS 攻击、注入攻击以及其他的病毒攻击。

控制结构

使用、混合、匹配所有备选的 if，while，for，foreach，switch 语法。如果被问起来，所有的这些，请解释说你正在培训新员工学习真正的语言。

if ($a > 5):
  if ($a > 4) {
      while ($a > 0):
        echo --$a;
      endwhile;
  }endif;

嵌套三元运算符，没有比这个更好、更简洁的代码了。

// 猜猜这里输出什么echo true ? 'true' : false ? 't' : 'f';

在 for 的循环体内，再次增加 $i 以保持所有人的注意。或者，通过不使用 $i 来实现循环增量的惊喜。从不。

嵌套循环、深入，然后突然跳出它们（循环）。像 break 2 和 break 3 这样的代码存粹是为了娱乐，尤其是当混合了奇怪的缩进代码时。

这是一个开始！

这就是今天的全部。我希望你相信你自己也能做到，你也可以编写不可维护的代码。现在你的未来就在你的手中！当然，你也可以编写可读性比较高的代码，但是冒着被替代的风险。

Practice makes perfect.

原文地址：http://www.phpied.com/how-to-write-unmaintainable-php-code-2009/

相关文章推荐：

1.  2019 PHP安全指南

2. PHP早已不是十年前的鸟样