It feels funny to me to obfuscate a user control. What is there to keep secret? Usually people obfuscate important algorithms. Admitted, to break an obfuscation, an attacker will try to start fooling around with user controls and see what modifications that does to the execution of the application. People with need for strong obfuscations normally do not obfuscate byte code languages. These have a tendency to be easy to de-obfuscate. Strong obfuscations are done on machine code programs. I'm doing obfuscations for business. Like the original poster I would love to know the quality of obfuscations. I bet my obfuscations are unbreakable by amateurs. But how can you find out security against sophisticated attackers? The solution is to pay a readteam. However,for my startup, I would not have the slightest idea where to take the money from. Maybe somebody might try it as a challenge or a crackme, just for bragging rights. But then. if somebody posts an opinion, how much would you believe it? Chris Chris Jacobi Founder White Hawk Software www.whitehawksoftware.com

A software architect is a good programmer and thinks ahead how the parts interoperate, whether or not the system is extensible and has good judgement to predict performance. A "software architect" which is not a good programmer is a disaster. One cannot have guts feeling about interoperability, extensability and performance without the skill to actually build the pieces. The grounding would be missing. While a manager can compensate not being a top-notch expert by using people skills, listening skills and listing to the best engineers, an architect cannot. Without the skills one makes a fool out of oneself when trying to tell professionals how to do their work. Well, the syntax details of a language might be the one thing which does not matter. A good software developer can do or is in the process of learning to do software architecture. But mediocre software developers can still code an algorithm without understanding the bigger picture.

When I develop software I want the process to be repeatable. E.G. I want to be able to use a fresh machine, re-install the tools and rebuild my software from source code. With cloud tools I do not have any control over whether or not I can re-create a particular version of my code. You may ask why don't I use the cloud for quick experiments or hobby? The answer may be unsatisfying, but I simply don't like to develop and learn complete new processes for quick experiments when I am in a deep rut of doing it professionally without big hurdles and everything is ready.

Marc, thanks for your comment. I have never written a style guide for the English language. Only a fool or an elementary school teacher would make the effort to read what I have to say about the English language; I certainly cannot refute your statement on polish. I disagree on whatever is the proper length. When I researched style guides I found some very short and to the point guides; I ignored many simply because I couldn't see the reasoning behind what they were saying. There is a 350 page book "Framework Design Guidelines" (mostly C#) [Google]. I think it is well written and has interesting inserts from different personalities. Nevertheless, I ignored most of it, mostly because it doesn't respect the limits of my attention span. Somewhat because is too general and doesn't contain what is specially important for my startup. And lastly, they didn't dare to disagree loudly enough with other standards. I think having some wiggle room is treating my cowerkers as professional adults. For the same reason it has very little trivial content. Examples would be nice, but most is for the benefit of programming-in-the-large, where I find it difficult to make reasonable examples. "Policing" is not something I like to do; The people I want to work with earn respect and absence of being policed. If you think there is nothing unusual and most is common sense, I think that this is a compliment to me, but in my opinion it also compliments on you. What has "Agile" have to do with "style?" Good question, but I am taking some wiggle room myself defining what is style. In what other document could I ramble about obsessive agile-ness in a reasonable way? And for anybody who has read till here: Google Marc on CodeProject; he has written some nice articles. Chris www.whitehawksoftware.com Edited to spell Marc's name corrctly.

You hit a slightly sour point in my standard: a) I think most rules are on a level a little bit higher then what automatic formatters can do. b) Fixing output of automatic formatters is painful. However, readability is so important to me that I pay the price. I am takeing your word on SQL, at least until a coworker will bring up that issue again. That choice may be important in a particular project, but I don't think the choice adds much value to a somewhat more generic style guide discussion. (I saw your :) )

Garth, I believe you are right or have a good point in everything you have mentioned. I will explain motivations not because I am defensive, but because it adds details to the discussion. I do agree about needing a living document; I do have some problems finding the right technology however. Once I have (more) coworkers, their input is a must; for a limited time PDF works fine. About changing the stance, I not only agree, but can admit that it already has happened a few times (E.g. what it says about lambdas). Big O notation: I do not want to belittle younger guys who haven't heard about it. In some sense this style is an example of mild project-dependence: In my particular application not being carefull with Big O notation would doom it pretty fast. And, on project dependency: It is somewhat hurtfull for me to be quiet on scheduling multiple processes, however my time limits and the specific purpose of the guide lead me to ommit features which are not relevant in my particular context. I found that admitting and even using some project dependencies made it much easier to come up with a useful guide. Code repositary, directory structures, maintenance policy are all out for 2 simple reasons: 1) I'm not experienced enough to know the best ways myself. 2) Once decided I think they will not be part of a style guide; they will be part of mandatory project rules. About a better place to post: I did some research to find a good place; I apologize if I wasn't thorough enough and used a wrong place. If people who know the right structure for this website can improve the placement, I am thankful. By the way if that other guy calls it spam, he is not completely off, just a little impolite: 1) I do have a spam component: Attracting the right guys around me was part of my goal... 2) I hate spam so much that I am willing to forgive some knee-jerk reactions against something he considers spam. Chris

Hi, for quite some time I am using my own C# style guide for my startup. It probably is among the C# style guides the one with the most variations from "official" style guides. However, all variations are principled and never just for the reason of being different. I would invite anybody to have a look at it. Maybe one or the other feature might prove beneficial for your own projects. It can be found here: http://chrisjacobi.wordpress.com[^] A separate discussion meta-topic might be: By using a style guide like this, will it attract stellar programmers because it is a nice style and gives enough individual freedom? Alternatively, would it deter first class programmers because they might oppose using a somewhat unusual style? Chris, www.whitehawksoftware.com[^]