Wer schreibt Microsoft-Supportartikel? Können sie immer vertrauenswürdig sein? [geschlossen]

Ich würde ihnen vertrauen, nicht bösartig zu sein, aber sie sind nicht immer guter Code. (MSDN-Beispiele sind manchmal ziemlich schrecklich.)

Hier ist zum Beispiel ein Code in dem Beispiel, das Sie angegeben haben:

Nun, hier gibt es zwei Probleme:

• Warum gilt es als gültig , einen Vergleicher ohne Sortierreihenfolge zu haben? Dies sollte ein Konstruktorparameter sein, der zum Zeitpunkt der Konstruktion IMO validiert wurde.
• Sie sollten nicht nur das Ergebnis eines Vergleichs negieren, um einen "umgekehrten Vergleich" durchzuführen. Das bricht, wenn das Ergebnis des ersten Vergleichs int.MinValue ist - weil -int.MinValue == int.MinValue . Es ist besser, die Argumente umzukehren, die für den ursprünglichen Vergleich verwendet wurden.

Es gibt andere Dinge, die ich in diesem Code in Frage stellen würde, aber diese beiden sollten ausreichen, um meinen Standpunkt zu verdeutlichen.

Ich stimme auch mit den anderen Antworten in Bezug auf: - Überprüfen Sie das Copyright / die Lizenz usw. des Codes, den Sie verwenden möchten - Stellen Sie sicher, dass Sie alles verstehen , das Sie verwenden möchten

Es würde Ihrem Chef wahrscheinlich nichts ausmachen, wenn Sie den Code nur in ein Testprojekt kopieren, mit dem Sie den Code testen und verstehen. Sie können dann verwenden, was Sie gelernt haben, den Produktionscode zu schreiben.

Und obwohl ich nicht glaube, dass jemand außerhalb von Microsoft die Namen der Leute kennt, die diese Supportartikel schreiben, stammen sie von demselben Hersteller wie Ihre Toolchain. Wenn Sie also den Support-Artikeln nicht vertrauen, dann Sie kann den Tools, die Sie gekauft haben, auch nicht vertrauen.

Microsoft Knowledge Base-Artikel zeigen sicheren (wie nicht bösartigen, aber nicht unbedingt sicheren) Code, aber normalerweise bietet das Beispiel den einfachsten möglichen Anwendungsfall. Es besteht eine gute Chance, dass Sie den Code ein wenig anpassen müssen, damit er so funktioniert, wie Sie möchten.

Sie sollten auch auf das Datum der Artikel achten. Zum Beispiel ist der Artikel, den Sie verlinken, fast drei Jahre alt. Es gibt definitiv einen besseren Weg, um mit dieser Situation fertig zu werden.

Beachten Sie, dass die meisten Codes in Artikeln dazu dienen, die Konzepte zu verstehen. Sie sind nicht "produktionsfertig". Lernen Sie stattdessen die Konzepte und implementieren Sie Ihre eigenen.

Wurde Ihnen aufgrund von Rechtsproblemen gesagt, dass Sie keinen Code aus dem Internet kopieren sollen? Wenn ja, dann müssen Sie sich nicht um diesen Microsoft-Code sorgen.

Ich würde Ihnen raten, keinen Code zu verwenden, den Sie nicht verstehen. Wenn Sie nicht sagen können, ob der Code bösartig ist oder nicht, verwenden Sie ihn nicht.

MSDN- und kb-Supportartikel werden von MS-Mitarbeitern geschrieben, die Teil des UX-Teams des jeweiligen Produkts sind (Benutzererfahrung). Dies sind Leute, die typischerweise einen Hintergrund im technischen Schreiben haben, aber nicht notwendigerweise Entwickler selbst sind (obwohl einige es sind). Es ist sehr üblich, dass das UX-Team mit Entwicklern an dem Produkt zusammenarbeitet, um sicherzustellen, dass die Codebeispiele korrekt sind. Allerdings ist diese Zusammenarbeit nach meiner Erfahrung eine der niedrigsten Prioritäten, die ein typischer MS-Entwickler hat und kann ignoriert werden, und so kann es manchmal dazu führen, dass schlechter Code rauskommt.

Damit stimme ich Carl Norums Kommentar vollkommen zu. Das Kopieren von Code, den Sie nicht verstehen, erfolgt auf eigenes Risiko. Stellen Sie sicher, dass Sie den Code verstehen, den Sie in Ihr Produkt eingeben!

Ich fand die Microsoft-Artikel immer von höchster Qualität (leider nicht ihre Produkte).

Es besteht jedoch immer die Gefahr einer Spoofing-Site.