Python中的缩进-解决方案选项

在绝大多数语言中,如果删除程序整个源代码中的所有缩进,然后应用自动格式设置,则程序将保持完全运行状态,并同时以相同的样式进行设计。

在Python的情况下,似乎无法执行此操作。

至少我找不到任何地方可以立即检测Python中的随机偏移量缩进。我必须自己解决这个问题。


介绍


亲爱的读者!
如果您的陈述很接近您:
1)编程是一门高技巧。
2)使用任何一种语言编程时,您都需要充分利用该语言的功能和多样性,以最小化源代码。
3)进行编程时,您需要在程序的源代码中显示出较高的水平,以便没人能说出您的程序是“哑巴”。

如果以上几点中的至少一个(!)距离您很近,请不要阅读本文!请不要浪费您的时间。
它将讨论一个完全遥不可及的荒谬的编程时刻。

亲爱的读者!
如果该声明已经接近您:
1)编程是例行的,相当单调的工作,就像挖一个无尽的缠绕沟。
2)当以任何一种语言编程时,您需要使用一组最低限度的最佳语言命令(可能会删除其大部分命令),以便即使是初级程序员也可以轻松地找出您的程序!
3)在编写程序时,在某种程度上应该是“哑巴”。这样,在您实施该项目后,您可以启动一个新项目,并冷静地让参与该项目的初级程序员根据客户的常规小新要求对其进行支持和完善。

如果以上所有这三个陈述对您都是正确的,那么也许您有一个问题,我想提供解决方案。

Python的主要缺点:

1) Python在使用资源及其数据方面没有“最小化”,因此不适合编写需要使用资源的程序,例如移动应用程序,低级程序(驱动程序,驻留程序等)。 。)等

2) Python速度很慢并且是单线程的(GIL-全局解释器锁定)。

3)在Python中,程序块仅基于缩进(!)。因为这:

  • 程序的“可读性”降低(见下文);
  • 源文本无法完全自动格式化;
  • 可能会因偶然的和未注意到的凹痕偏移而发生错误,有时很难发现和纠正。

Python的第一个缺点是难以消除,在这里它的使用范围受到限制。但这是自然的时刻,因为 不可能想出在所有任务领域都最有效的语言。

Python的第二个缺点是它与C / C ++具有出色的双向互操作性。

通常,一个成功的项目发展很快。首先,没有高性能要求,在Python中,如有必要,可以使用C / C ++中的微小插入。
但是随着项目的发展和扩展,性能要求也相应提高,Python越来越多地开始实现C / C ++中被调用语言的功能。同时,Python本身的作用并没有减少,因为当对不需要很高执行速度的部分进行编程时(在大型项目中通常有很多),Python是比C / C ++更方便的工具。

对于Python的第三个缺点,我想提供自己的解决方案。

大家都知道,对于绝大多数语言来说,源文本自动格式化非常常用。

那些。不管用这种语言编写的程序是哪种缩进形式,当您开始自动格式化时,所有缩进形式都将变为其标准格式。对于Python,这似乎是不可能的。

任何使用数千种语言编写项目的程序员都知道,开发过程不仅是在发明下一部分程序并将其填充,而且还在不断将代码段移至子程序,现在在程序块之间,然后移至通用外部模块等。 P.

此外,在实践中,已经在最初阶段使用了程序的第一个大纲的用户/客户开始更改和补充最终项目的任务,这导致对源代码的强烈调整。

然后在Python中,如果别人的(!)程序的数十个片段(或您自己的,但是您根本不记得的)发生了重大变化,那么在转移一个块时意外地捕获属于另一个块的另一段代码是值得的,该程序可能会保持完全正常运行,但是其工作算法会发生变化(请阅读“程序将开始无法正常运行”),并且有时很难找到其他人程序中此类错误的位置,然后正确还原缩进!

当然,在这种情况下,您可以查看源文本(在更改之前),但是如果您已经在该位置进行了许多更正,则必须“放松”整个更正链。

解决Python中的缩进问题


Python中的缩进由以下命令组成:

- class
- def

- for
- while

- if

- try

- with

为了消除对缩进的依赖,对于每个命令,我决定将使用“最终”命令作为规则,这肯定会关闭命令块(缩进)。

类和def命令


对于class / def命令,完成缩进块通常没有问题,因为 使用新的class / def命令关闭该块。

唯一的情况是在另一个子程序/方法中声明了一个或多个子程序。

def ppg_1():
    def ppg_2():
        ...  ppg_2 ...
    def ppg_3():
        ...  ppg_3 ...
        ...  ppg_3 ...
        ...  ppg_3 ...
    ...  ppg_1 ...

然后,如果不小心移动了最后一个内部子程序的指令块,则它将与声明该内部子程序的子程序/方法的命令合并。

def ppg_1():
    def ppg_2():
        ...  ppg_2 ...
    def ppg_3():
        ...  ppg_3 ...
    ...  ppg_3 ...
    ...  ppg_3 ...
    ...  ppg_1 ...

在这种情况下,只需在此内部例程/方法的末尾添加“ return”,即可清楚地指示其命令块的结尾。

def ppg_1():
    def ppg_2():
        ...  ppg_2 ...
    def ppg_3():
        ...  ppg_3 ...
        ...  ppg_3 ...
        ...  ppg_3 ...
        return
    ...  ppg_1 ...

for和while命令


在“ for”和“ while”语句的末尾,您需要输入“ continue”。

那些。该命令将如下所示:

for  <...> :             #  
    ...  ....
    continue             #  



while  <...> :           #  
    ...  ....
    continue             #  

例如:
        ...  ...

        for i in range(10):
            ...  for ...

            ...  for  ...

            ...  for  ...

        ...  ...

意外删除“ for”块的最后一个命令中的缩进不会导致程序执行错误,但会导致错误的结果!如果您不知道程序的算法(例如,如果它是退休同事的程序),那么很难找到这种失败!

就是这样:
        ...  ...

        for i in range(10):
            ...  for ...

        ...  for  ...

        ...  for  ...

        ...  ...

在以下示例中,意外删除缩进将立即引发错误:
        ...  ...

        for i in range(10):
            ...  for ...

            ...  for  ...

            ...  for  ...

            continue

        ...  ...

如果命令


在“ if”语句的末尾,您需要放置命令“ elif 0:通过”,而不是“ else”使用命令“ elif 1:”。

那些。对于“如果”,将有完整的命令块:

if <>                      #  
    ...  ....
elif <>
    ...  ....
elif 1:                    #  "else"
    ...  ....
elif 0: pass               #  

例如:
        ...  ...

        if  result != -1 :

            ...  if ...

            ...  if ...

            ...  if ...

        elif 0: pass

        ...  ...

如果如上所示,则在“ if ... elif 0:通过”命令块中,缩进将生成启动错误。

如果没有“ elif 0:通过”,则如果不小心删除了“ if”块最后几行中的缩进,那么您将首先查找导致程序无法正确启动的位置,然后考虑哪些缩进应在块中以及哪些缩进-不
        ...  ...

        if  result != -1 :

            ...  if ...

        ...  if ...

        ...  if ...

        ...  ...

在我看来,为什么还要关闭由运算符“ for”,
“ while”,“ if”等创建的命令块……

因为当您查看一段代码
时,当前行的末尾之间的缩进级别存在很大差异在下一个块和下一个开始时,您通常无法再了解哪个缩进属于什么。

然后,除了防止意外删除外,带有“ continue”和“ elif 0:pass”的构造还可以让您指出您从哪个块开始并对其进行注释

例如,您看到一个大块的结尾:

                            ...  ...

                            ...  ...

                            ...  ...

                            ...  ...

                        ...  ...

                        ...  ...

                        ...  ...

                        ...  ...

    elif result == 1 :

        ...  ...

        ...  ...

        ...  ...

        ...  ...

而且很难记住每个缩进级别的含义。

但是看起来像这样要容易得多:

                            ...  ...

                            ...  ...

                            ...  ...

                            ...  ...

                            continue    #   b'\\r\\n'   

                        ...  ...

                        ...  ...

                        ...  ...

                        ...  ...

                    elif 0: pass     #  " "  " "

                elif 0: pass         #   . - 

                continue             #    

            continue                 #  .,  -  " "
                      
    elif result == 1 :

        ...  ...

        ...  ...

        ...  ...

        ...  ...

尝试命令


与“ if”完全相似。

try:                   #  
    ...  ....
except <...>:
    ...  ....
except 1:              #  "else"
    ...  ....
except 0: pass         #  

唯一的问题是finally:命令之后,您将无法再放置当前try块的任何命令。

因此,如果需要使用它,则为了保留自动格式化的可能性并防止意外删除缩进,您需要在本地子程序中的“ finally:”之后删除整个命令块(即,将其声明为当前子程序中的一个子程序)。

那些。带有“ finally:”的文本将如下所示:

    def my_ppg():
        ...
        return

    ...

    finally:
        my_ppg()

    ...

在这种情况下,您也可以安全地应用自动格式设置,而不必担心
意外删除缩进。

“使用”命令


Python中没有用于“ with”的其他命令,可以用作块的结尾。因此,与的情况类似于最终的情况。
那些。我们要么将在“ with”语句块中执行的所有命令都转移到本地子例程中,要么……但是然后我会说一个非常亵渎的事情:“ ...或者您只是不需要使用它。”

事实是,一方面,“ with”只是现有Python命令的“包装器”(也就是说,您始终可以用一组类似的命令来替换它);另一方面,实践表明,对于初级程序员而言,这种情况经理很难全面发展。因此,如果您希望初级程序员在您执行之后冷静地陪同已实施的项目,则无需在项目中使用妨碍其工作的团队。

结论



我想您已经理解,如果您使用ANYWHERE(!)在Python中编写程序,上述创建缩进块的技术中,即使您歪斜或完全删除其中的缩进,编写完全自动格式化的程序也是很容易的,因为 对于所有命令块,都有块的开头和结尾,与缩进无关。

现在,带着微笑,我们提出这样的问题:“如果正确格式化缩进块,在必要时与C / C ++进行交互并且不在移动和资源关键型应用程序中使用Python,Python的缺点是什么?”

答:“只有微小的缺陷。那些。总的来说-不。”

通过提出这样的问题,我们只能享受Python的主要优势。

  1. 简单。
  2. 站点的最小测试周期:书面启动检查。
  3. 强大-Python的库/框架“针对每种口味和颜色”。

在我看来,这三个优点共同构成了该语言的近乎完美的版本(请记住,这仅受上述问题中指定的条件的限制!)。

All Articles