Less Comments, More Readable Code

I’m currently implementing a drag and drop sorting feature for a tree view in a Windows Forms application. We’re using Infragistics UI controls, and their UltraTree doesn’t have drag and drop functionality out of the box. They do however have a sample in their SDK which explains how to implement it. Here’s an excerpt of that sample code – a method which determines where to draw a marker which tells the user where in the tree he’s about to drop (ie before or after the node the mouse pointer hovering):

public void SetDropHighlightNode(UltraTreeNode Node, Point PointInTreeCoords )

{

     //The distance from the edge of the node used to

     //determine whether to drop Above, Below, or On a node

     int DistanceFromEdge;

     //The new DropLinePosition

     DropLinePositionEnum NewDropLinePosition;

     DistanceFromEdge = mvarEdgeSensitivity;

     //Check to see if DistanceFromEdge is 0

     if (DistanceFromEdge == 0)

     {

         //It is, so we use the default value - one third.

         DistanceFromEdge = Node.Bounds.Height / 3;

     }

     //Determine which part of the node the point is in

     if (PointInTreeCoords.Y < (Node.Bounds.Top + DistanceFromEdge))

     {

         //Point is in the top of the node

         NewDropLinePosition = DropLinePositionEnum.AboveNode;

     }

     else

     {

         if (PointInTreeCoords.Y > ((Node.Bounds.Bottom - DistanceFromEdge) - 1))

         {

             //Point is in the bottom of the node

             NewDropLinePosition = DropLinePositionEnum.BelowNode;

         }

         else

         {

             //Point is in the middle of the node

             NewDropLinePosition = DropLinePositionEnum.OnNode;

         }

     }

     //Now that we have the new DropLinePosition, call the

     //real proc to get things rolling

     SetDropHighlightNode(Node, NewDropLinePosition);

}

Disregarding the clearly redundant comments (NewDropLinePosition is “the new DropLinePosition”?   phew, I’d never have guessed!), there are some that you might think deserve to stay – the ones that tell you what the if/else conditions are checking for, for instance.

However, take a look at my refactored version of this method. It has ZERO comments – yet I would argue that it is much easier to understand:

public void HighlightPotentialDropNode(      
                     UltraTreeNode potentialDropNode, 
                     Point dropLocationRelativeToTree)

{

    DropLinePositionEnum newDropLinePosition = DropLinePositionEnum.OnNode;

    if (PointIsAboveNode(potentialDropNode, dropLocationRelativeToTree))

    {

        newDropLinePosition = DropLinePositionEnum.AboveNode;

    }

    else if (PointIsBelowNode(potentialDropNode, dropLocationRelativeToTree))

    {

        newDropLinePosition = DropLinePositionEnum.BelowNode;

    }

    DrawDropLinePosition(potentialDropNode, newDropLinePosition);

}

private bool PointIsAboveNode(UltraTreeNode node, Point pointInTreeCoords)

{

    return pointInTreeCoords.Y < (node.Bounds.Top + EdgeSensitivity);

}

private bool PointIsBelowNode(UltraTreeNode node, Point pointInTreeCoords)

{

    return pointInTreeCoords.Y > ((node.Bounds.Bottom - EdgeSensitivity) - 1);

}

Apart from renaming stuff to give them more meaningful names, notice particularly how I’ve used extract method on the predicates of the if statements, giving them names which clearly state what the conditions are. This has an important effect: All the code in this method is now at the same level of abstractionand this makes it much more readable.

Extract method is probably the simplest and most effective refactoring tool in your arsenal. Use it lavishly! If you want to learn more about writing clean functions, I suggest you take an hour to watch Robert C. Martin’s great “Clean Code: Functions” talk – here’s a recording from NDC 2009 (see more NDC recordings here).

 

 

 

In my last post, I refactored some horribly commented code into the following:

public void HighlightPotentialDropNode(      
                     UltraTreeNode potentialDropNode, 
                     Point dropLocationRelativeToTree)

{

    DropLinePositionEnum newDropLinePosition = DropLinePositionEnum.OnNode;

    if (PointIsAboveNode(potentialDropNode, dropLocationRelativeToTree))

    {

        newDropLinePosition = DropLinePositionEnum.AboveNode;

    }

    else if (PointIsBelowNode(potentialDropNode, dropLocationRelativeToTree))

    {

        newDropLinePosition = DropLinePositionEnum.BelowNode;

    }

    DrawDropLinePosition(potentialDropNode, newDropLinePosition);

}

private bool PointIsAboveNode(UltraTreeNode node, Point pointInTreeCoords)

{

    return pointInTreeCoords.Y < (node.Bounds.Top + EdgeSensitivity);

}

private bool PointIsBelowNode(UltraTreeNode node, Point pointInTreeCoords)

{

    return pointInTreeCoords.Y > ((node.Bounds.Bottom - EdgeSensitivity) - 1);

}

I was a bit quick to publish that post – because 5 minutes later I discovered that I wasn’t quite done cleaning up this method... Can you tell what’s wrong with it? It’s breaking the single responsibility principle.

Let’s do one more ‘extract method’ refactoring on it, putting the logic of calculating the DropLinePosition in a separate method:

public void HighlightPotentialDropNode(      
                        UltraTreeNode potentialDropNode, 
                        Point dropLocationRelativeToTree )

{

    DropLinePosition dropLinePosition = 
                CalculateDropLinePosition(potentialDropNode, dropLocationRelativeToTree);      

    DrawDropLinePosition(potentialDropNode, dropLinePosition);

}

private DropLinePosition CalculateDropLinePosition(      
                                   UltraTreeNode potentialDropNode, 
                                   Point dropLocationRelativeToTree)

{

    DropLinePosition dropLinePosition = DropLinePosition.OnNode;

    if (DropLocationIsAboveNode(potentialDropNode, dropLocationRelativeToTree))

    {

        dropLinePosition = DropLinePosition.AboveNode;

    }

    else if (DropLocationIsBelowNode(potentialDropNode, dropLocationRelativeToTree))

    {

        dropLinePosition = DropLinePosition.BelowNode;

    }

    return dropLinePosition;

}

private bool DropLocationIsAboveNode(UltraTreeNode node, Point dropLocationRelativeToTree)

{

    return dropLocationRelativeToTree.Y < (node.Bounds.Top + EdgeSensitivity);

}

private bool DropLocationIsBelowNode(UltraTreeNode node, Point dropLocationRelativeToTRee)

{

    return dropLocationRelativeToTRee.Y > ((node.Bounds.Bottom - EdgeSensitivity) - 1);

}

 

基于STM32 F4的永磁同步电机无位置传感器控制策略研究内容概要:本文围绕基于STM32 F4的永磁同步电机(PMSM)无位置传感器控制策略展开研究,重点探讨在不依赖物理位置传感器的情况下,如何通过算法实现对电机转子位置和速度的精确估计与控制。文中结合嵌入式开发平台STM32 F4,采用如滑模观测器、扩展卡尔曼滤波或高频注入法等先进观测技术,实现对电机反电动势或磁链的估算,进而完成无传感器矢量控制(FOC)。同时,研究涵盖系统建模、控制算法设计、仿真验证(可能使用Simulink)以及在STM32硬件平台上的代码实现与调试,旨在提高电机控制系统的可靠性、降低成本并增强环境适应性。; 适合人群:具备一定电力电子、自动控制理论基础和嵌入式开发经验的电气工程、自动化及相关专业的研究生、科研人员及从事电机驱动开发的工程师。; 使用场景及目标:①掌握永磁同步电机无位置传感器控制的核心原理与实现方法;②学习如何在STM32平台上进行电机控制算法的移植与优化;③为开发高性能、低成本的电机驱动系统提供技术参考与实践指导。; 阅读建议:建议读者结合文中提到的控制理论、仿真模型与实际代码实现进行系统学习,有条件者应在实验平台上进行验证,重点关注观测器设计、参数整定及系统稳定性分析等关键环节。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值