Topics

Featured in Development

Alex Bradbury gives an overview of the status and development of RISC-V as it relates to modern operating systems, highlighting major research strands, controversies, and opportunities to get involved.

Featured in Architecture & Design

Will Jones talks about how Habito, the leading digital mortgage broker, benefited from using Haskell, some of the wins and trade-offs that have brought it to where it is today and where it's going next. He also talks about why functional programming is beneficial for large projects, and how it helps especially with migrating the data store.

Featured in AI, ML & Data Engineering

Katharine Jarmul discusses research related to fair-and-private ML algorithms and privacy-preserving models, showing that caring about privacy can help ensure a better model overall and support ethics.

Featured in Culture & Methods

This personal experience report shows that political in-house games and bad corporate culture are not only annoying and a waste of time, but also harm a lot of initiatives for improvement. Whenever we become aware of the blame game, we should address it! DevOps wants to deliver high quality. The willingness to make things better - products, processes, collaboration, and more - is vital.

Featured in DevOps

Service mesh architectures enable a control and observability loop. At the moment, service mesh implementations vary in regard to API and technology, and this shows no signs of slowing down. Building on top of volatile APIs can be hazardous. Here we suggest to use a simplified, workflow-friendly API to shield organization platform code from specific service-mesh implementation details.

SDK for StyleCop Released

Unlike Microsoft's FXCop, which was largely celebrated as an important step towards improving the consistency and quality of .NET code, StyleCop has been viewed with much suspicion. The main difference between the two is that FXCop focuses on compiled code from any .NET language while StyleCop works solely against C# source code.

The biggest complain about StyleCop is that its recommendations are mainly based in opinion. While some of the guidelines in FXCop are subjective, most are grounded in sound logic based on a deep knowledge of how the CLR works. StyleCop, on the other hand, is mostly about hotly debated issues like how many spaces to use for indention. Some are even downright contrary to standard practices like placing "using" statements inside namespaces.

With the release of the StyleCop SDK, developers can develop their own rules to supplement or outright replace the default ones. While in the long run developers are going to want to be able to simple configure the rules to match their company standards, this is at least a good temporary solution.

In addition to creating new rules, developers will find information in the SDK on how to integrate StyleCop in MSBuild tasks.

Tell us what you think

Community comments

Of all the examples..

Your message is awaiting moderation. Thank you for participating in the discussion.

Some are even downright contrary to standard practices like placing "using" statements inside namespaces.

Of all the examples that could be taken... I wouldn't be surprised to someday find this particular one as part of FxCop... While many of StyleCops rules are subjective (read: make people sad because their "flawless" naming conventions are not all that flawless, or are totally obsolete as they're simply ported from older environments with different restrictions and requirements), that particular one has to do with how the compiler works, and is meant to catch as many errors as possible at compile time and remove ambiguity.

The standard Visual Studio templates have never followed -any- convention, and contredict each other...thats not new.