爲什麼這段代碼不好？

下面是rss reader的C＃代碼，爲什麼這段代碼不好？這個類將生成5個最近發佈的帖子，按標題排序。你用什麼來分析C＃代碼？爲什麼這段代碼不好？

static Story[] Parse(string content) 
    { 
     var items = new List<string>(); 
     int start = 0; 
     while (true) 
     { 

      var nextItemStart = content.IndexOf("<item>", start); 
      var nextItemEnd = content.IndexOf("</item>", nextItemStart); 
      if (nextItemStart < 0 || nextItemEnd < 0) break; 

      String nextItem = content.Substring(nextItemStart, nextItemEnd + 7 - nextItemStart); 
      items.Add(nextItem); 
      start = nextItemEnd; 
     } 

     var stories = new List<Story>(); 
     for (byte i = 0; i < items.Count; i++) 
     { 
      stories.Add(new Story() 
      { 
       title = Regex.Match(items[i], "(?<=<title>).*(?=</title>)").Value, 
       link = Regex.Match(items[i], "(?<=<link>).*(?=</link>)").Value, 
       date = Regex.Match(items[i], "(?<=<pubDate>).*(?=</pubdate>)").Value 
      }); 
     } 

     return stories.ToArray(); 
    }

來源

2012-09-26 Sofic

你能否描述你的意思是「壞」？雖然我可以說一件事，爲什麼不使用LINQ to XML來解析這個？ –

錯誤意味着垃圾代碼或具有文體，功能，可維護性問題。 – Sofic

如果沒有某種度量標準，某些東西不可能是好的或壞的。這些代碼可以通過多種方式完成，但是如果不理解您想要最大化的內容，很難理解要改進的內容。 – madmik3

這是不好的，因爲它是在解析XML的框架中使用字符串解析時的excellent classes。更好的是，有classes來處理RSS提要。

ETA：

很抱歉不能早點回答你的第二個問題。有很多工具可以分析C＃代碼的正確性和質量。有可能介於編譯一個巨大的名單，但這裏有幾個我日常使用的基礎上，以幫助確保高質量代碼：

StyleCop（代碼格式化標準）
Resharper（慣用編程，疑難雜症捕）
FxCop（代碼的正確性，標準遵守，慣用的編程）
Pex（白箱測試）
Nitriq（碼質量度量）
NUnit（單元測試）

來源

2012-09-26 01:00:13

爲什麼不使用XmlReader或XmlDocument或LINQ to Xml？

來源

2012-09-26 00:56:55 yukaizhao

+1 - 完全 - 解析器我們是爲代碼試圖解決的問題而設計的。另外，在n個字節的循環內執行RegEx匹配可能會很昂貴。像7這樣的魔術數字恰好與代碼中的字符串常量進一步對齊... – bryanmac

您不應該使用字符串函數和正則表達式來解析XML。 XML可以變得非常複雜，並且可以像XmlReader這樣的真正的XML解析器可以處理的許多方式格式化，但會破壞簡單的字符串解析代碼。基本上：不要試圖重新發明輪子（一個XML解析器），尤其是當你不知道輪子實際上有多複雜時。

來源

2012-09-26 00:58:58 PherricOxide

我認爲代碼最糟糕的是性能問題。您應該將xml字符串解析爲XDocument（或類似的結構），而不是一次又一次使用正則表達式解析它。

來源

2012-09-26 00:59:06

對於初學者來說，它使用byte作爲索引，而不是int（如果items中有更多的項目比byte能代表什麼呢？）。它不使用慣用的C＃（請參閱user1645569的響應）。它也不必要地使用var而不是特定的數據類型（雖然這樣更具風格，但對於我來說我不喜歡，因此按我的指標來看它並不理想（並且你沒有給出其他指標））。

讓我澄清一下我在說什麼「不必要地使用var」：var本身並不壞，我並不是這樣說的。我（主要）暗示這裏的用法不是很一致。例如，明確聲明start爲int，但隨後宣佈nextItemEnd爲var（將演繹到int）和想要自動推斷變量的類型，並明確聲明它之間分配nextItemEnd到start看來（我）像一個奇怪的混合物。我認爲在start的聲明中沒有使用var是很好的（因爲那麼它的意圖是整數還是浮點數並不完全清楚），但我（個人）認爲它不會幫助任何人聲明nextItemStart和nextItemEnd as var。我傾向於將var用於更復雜/更長的數據類型（類似於我在迭代器中使用C++中的auto，但不適用於「更簡單」的數據類型）。

來源

2012-09-26 00:59:16 Cornstalks

-1的說明請嗎？ – Cornstalks

我還沒有投票，但建議使用var作爲局部變量 –

@sleimanjneidi：謝謝，也許這就是爲什麼。我會澄清說''var'本身並不壞。我對'var'沒有任何反應;我只是覺得它在這裏用處不大（如果他將'start'聲明爲'int'，然後'nextItemEnd'聲明爲'var'，然後將'nextItemEnd'分配給'start'，我個人更喜歡他與顯式聲明類型一致，而不是在'int'和'var'之間切換）。 – Cornstalks

只是因爲你正在改造一，使用Linq to xml相反，它是非常簡單和clean.I相信你能做到以上三行代碼，如果你使用Linq to XML，你的代碼使用了大量的魔法數字（例如：7-n ..），這使得它不穩定和非通用的東西

來源

2012-09-26 01:01:53

爲什麼這段代碼不好？

回答

相關問題