PVS-Studio team creates new diagnostic rules, and gradually refines the existing ones. We've recently enhanced one of the oldest diagnostic rules in the C# analyzerPVS-Studio team creates new diagnostic rules, and gradually refines the existing ones. We've recently enhanced one of the oldest diagnostic rules in the C# analyzer

How to Prevent Your Code From Turning Into Sausage That Goes Beyond the Screen

Today, we’ll talk about a bug that shows in practice and how "code sausage" can cause a series of problems related to the last line effect and careless copy-paste, as well as lead to new errors.

\ The PVS-Studio team not only creates new diagnostic rules, but also gradually refines the existing ones. For example, we've recently enhanced one of the oldest diagnostic rules in the C# analyzer, V3001, to make it detect redundant parentheses more accurately. As a result, the analyzer started detecting new bugs, one of which we show you.

\ This case was detected in the Space Engineers project; this is one of the projects in our internal regression testing database. We use a specific old project version to compare how the analyzer behaves on the same code across updates. But if we look at the latest source code, we'll find that the bug is still there. Let's take a look at the Contains function in BoundingBox.cs.

\ See the problem? Probably not.

\ Why's that? Because long and indecipherable code lines are developers' foes that should be avoided. It's very easy to make a mistake there, as you can see. Let's rewrite the code a little bit to make it clearer.

public ContainmentType Contains(BoundingSphere sphere) { Vector3 result1; Vector3.Clamp(ref sphere.Center, ref this.Min, ref this.Max, out result1); float result2; Vector3.DistanceSquared(ref sphere.Center, ref result1, out result2); float num = sphere.Radius; if ((double)result2 > (double)num * (double)num) return ContainmentType.Disjoint; return (double)this.Min.X + (double)num > (double)sphere.Center.X || (double)sphere.Center.X > (double)this.Max.X - (double)num || ((double)this.Max.X - (double)this.Min.X <= (double)num || (double)this.Min.Y + (double)num > (double)sphere.Center.Y) || ((double)sphere.Center.Y > (double)this.Max.Y - (double)num || (double)this.Max.Y - (double)this.Min.Y <= (double)num || ((double)this.Min.Z + (double)num > (double)sphere.Center.Z || (double)sphere.Center.Z > (double)this.Max.Z - (double)num)) || (double)this.Max.X - (double)this.Min.X <= (double)num ? ContainmentType.Intersects : ContainmentType.Contains; }

\ Better now, yeah? However, we have to make an effort to spot the error, though. Take a look at the last line of the logical condition:

(double)this.Max.X - (double)this.Min.X <= (double)num

\ As we can see, it duplicates the third line. The condition is enclosed in extra parentheses, but they're superfluous, as all checks are joined with the OR operator anyway.

\ In practice, there should be a check of the Z coordinate:

(double)this.Max.Z - (double)this.Min.Z <= (double)num

\ The analyzer detects it and issues a warning: V3001 There are identical sub-expressions '(double)this.Max.X - (double)this.Min.X <= (double)num' to the left and to the right of the '||' operator.

\ This is a good example of how a static analyzer complements code review because it's strenuous to manually discern a little typo in such a massive line. We like to call such code "code sausage"—and we've already written a note about how it lures bugs to your code.

\ The "last line effect" is also shown in all its glory. Typos most often appear at the end of similar code fragments. Technically, we can't talk about lines, since there is a single line. However, the idea still applies: the error occurred in the very last segment of a long, repetitive block.

\ The bug came from a copy-paste typo. Most likely, developers have copied one sub-expression, pasted it as a new one, and just forgotten to modify it. However, that's not all: this entire line with the error has been copied again and shows up just a few lines below, in the nearby Contains function:

public void Contains(ref BoundingSphere sphere, out ContainmentType result) { .... if ((double)result2 > (double)num * (double)num) result = ContainmentType.Disjoint; else result = (double)this.Min.X + (double)num > (double)sphere.Center.X || (double)sphere.Center.X > (double)this.Max.X - (double)num || ((double)this.Max.X - (double)this.Min.X <= (double)num || (double)this.Min.Y + (double)num > (double)sphere.Center.Y) || ((double)sphere.Center.Y > (double)this.Max.Y - (double)num || (double)this.Max.Y - (double)this.Min.Y <= (double)num || ((double)this.Min.Z + (double)num > (double)sphere.Center.Z || (double)sphere.Center.Z > (double)this.Max.Z - (double)num)) || (double)this.Max.X - (double)this.Min.X <= (double)num ? ContainmentType.Intersects : ContainmentType.Contains; }

It's the same issue with the same warning from the analyzer.

Conclusion

There's no need to go into a long explanation of why this code is problematic, as well as how it should be changed to avoid specific errors. Our readers probably already know that it all comes down to following these tips:

  1. Use table-style code formatting.
  2. Place the similar code in functions.
  3. Avoid redundant operations. For example, instead of type casting of (double)num everywhere, we could simply declare the num variable as double.
  4. Run PVS-Studio static analyzer regularly for additional control.

\

Piyasa Fırsatı
PVS Logosu
PVS Fiyatı(PVS)
$0.002256
$0.002256$0.002256
+5.22%
USD
PVS (PVS) Canlı Fiyat Grafiği
Sorumluluk Reddi: Bu sitede yeniden yayınlanan makaleler, halka açık platformlardan alınmıştır ve yalnızca bilgilendirme amaçlıdır. MEXC'nin görüşlerini yansıtmayabilir. Tüm hakları telif sahiplerine aittir. Herhangi bir içeriğin üçüncü taraf haklarını ihlal ettiğini düşünüyorsanız, kaldırılması için lütfen service@support.mexc.com ile iletişime geçin. MEXC, içeriğin doğruluğu, eksiksizliği veya güncelliği konusunda hiçbir garanti vermez ve sağlanan bilgilere dayalı olarak alınan herhangi bir eylemden sorumlu değildir. İçerik, finansal, yasal veya diğer profesyonel tavsiye niteliğinde değildir ve MEXC tarafından bir tavsiye veya onay olarak değerlendirilmemelidir.

Ayrıca Şunları da Beğenebilirsiniz

The Channel Factories We’ve Been Waiting For

The Channel Factories We’ve Been Waiting For

The post The Channel Factories We’ve Been Waiting For appeared on BitcoinEthereumNews.com. Visions of future technology are often prescient about the broad strokes while flubbing the details. The tablets in “2001: A Space Odyssey” do indeed look like iPads, but you never see the astronauts paying for subscriptions or wasting hours on Candy Crush.  Channel factories are one vision that arose early in the history of the Lightning Network to address some challenges that Lightning has faced from the beginning. Despite having grown to become Bitcoin’s most successful layer-2 scaling solution, with instant and low-fee payments, Lightning’s scale is limited by its reliance on payment channels. Although Lightning shifts most transactions off-chain, each payment channel still requires an on-chain transaction to open and (usually) another to close. As adoption grows, pressure on the blockchain grows with it. The need for a more scalable approach to managing channels is clear. Channel factories were supposed to meet this need, but where are they? In 2025, subnetworks are emerging that revive the impetus of channel factories with some new details that vastly increase their potential. They are natively interoperable with Lightning and achieve greater scale by allowing a group of participants to open a shared multisig UTXO and create multiple bilateral channels, which reduces the number of on-chain transactions and improves capital efficiency. Achieving greater scale by reducing complexity, Ark and Spark perform the same function as traditional channel factories with new designs and additional capabilities based on shared UTXOs.  Channel Factories 101 Channel factories have been around since the inception of Lightning. A factory is a multiparty contract where multiple users (not just two, as in a Dryja-Poon channel) cooperatively lock funds in a single multisig UTXO. They can open, close and update channels off-chain without updating the blockchain for each operation. Only when participants leave or the factory dissolves is an on-chain transaction…
Paylaş
BitcoinEthereumNews2025/09/18 00:09
Solana Prepares Major Consensus Upgrade with Alpenglow Protocol

Solana Prepares Major Consensus Upgrade with Alpenglow Protocol

TLDR: Alpenglow reduces Solana finality from 12.8 seconds to 100-150 milliseconds, a 100-fold improvement. Votor enables one or two-round block finalization through
Paylaş
Blockonomi2026/01/03 02:29
The Role of Reference Points in Achieving Equilibrium Efficiency in Fair and Socially Just Economies

The Role of Reference Points in Achieving Equilibrium Efficiency in Fair and Socially Just Economies

This article explores how a simple change in the reference point can achieve a Pareto-efficient equilibrium in both free and fair economies and those with social justice.
Paylaş
Hackernoon2025/09/17 22:30