#981 – Full List of C# Keywords

Total standard C# keywords

2,000 Things You Should Know About C#

In C#, identifiers are names that you choose to use for things like variables, classes, interfaces, etc.

A keyword is a reserved name that has a specific meaning and that you can’t (generally) use as an identifier.

Here’s the full list of standard keywords in C#:

 abstract  add  as  ascending
 async  await  base  bool
 break  by  byte  case
 catch  char  checked  class
 const  continue  decimal  default
 delegate  descending  do  double
 dynamic  else  enum  equals
 explicit  extern  false  finally
 fixed  float  for  foreach
 from  get  global goto
group  if  implicit  in
 int  interface  internal  into
 is  join  let  lock
 long  namespace  new  null
 object  on  operator  orderby
 out  override  params  partial
 private  protected  public  readonly
 ref  remove  return  sbyte
 sealed  select  set  short
 sizeof  stackalloc  static  string
 struct  switch  this  throw
 true  try  typeof  uint
 ulong  unchecked  unsafe  ushort
 using  value  var  virtual
 void  volatile  where  while

View original post


Let’s Stop the Async Suffix Bullshit

There is a common pattern that is used in .NET APIs where anything that returns a Task has the suffix Async.

However, in reality this is just another form of Hungarian Notation. “But Microsoft do it in the BCL” you may say. And of course you are right. Buts lets be clear – they had to as they already had synchronous versions of the APIs from previous versions of .NET.

So the Async suffix really came from expediency rather than a proposed standard pattern. In fact, where the API already support the Event Async Pattern (EAP) there already existed a version of the API with an Async suffix so they had to use TaskAsync to disambiguate.

If you have to support both a sync and async version of an API then maybe still use it – or rather, to encourage async interaction suffix the synchronous version with a Sync suffix…

View original post 28 more words


Which programming language to use when solving a problem in specific domain?


Unix/Linux scripting, system administration, one liners and command line utilities.


Science, mathematics, machine learning, Raspberry Pi, web development, desktop applications, and command line utilities.


Simple to medium-sized and agile web development.


Bourne shell replacement, simple unix scripting, and used when no better language implementations available.


Exploratory programming and practical JVM language.


What can go in a sysadmin’s work portfolio?

Andy Lester

A portfolio of your work is a great way to show at the job interview that you are able to produce work that the hiring manager wants. Anyone can make claims as to his skills and abilities, but producing tangible evidence of those skills makes it clear, and reduces the risk for the interviewer. Bringing a portfolio also puts you above other candidates who don’t.

For programmers, code samples are the most obvious work product to bring, but what about sysadmins? Jeffery Land writes:

I was curious about what you suggest for a systems administrator to bring in a portfolio? Most of the work revolves around resource management and troubleshooting issues. At the end of the day this pretty much just leaves you with the experience and nothing you can really point to. I’ve been putting together a blog with my experience that I point out to potential employers but…

View original post 316 more words


How to make commenting code fun?

Comment, comment comment. It must been a hell of a side job as a programmer or similar to do. We are programmers, we writes code, not documents, yada yada..

Well, that is what I thought in the first place.


Commenting is very very important in a long term or growing project. No matter how beautiful and readable your ‘self-documenting code’ will be. Why? The key is again, why?

Your code already does what it does, tell the computer to do things, and tell you what it does. However, why the code is even there in the first place? Why?

The first step to make documenting and reading it as a fun thing is, make it tell you why the code is there.

For instance, you have a function that writes to a configuration file on a Linux hosting server with only FTP access without SSH (I know it sucks, consider alternatives including DigitalOcean for VPS-like hosting or Bluehost also Dreamhost for SSH access).

An example comment for this scenario is – the server doesn’t have SSH access to execute Linux commands, so we implement this to write the code invoked from the execution of the web app.

And there ladies and gentleman, will make your life easier by commenting why instead of what.

Don’t repeat the code, assume the audience already understand the language and algorithm, and it is their fault for not taking enough time and effort to understand it (unless you writing clever code and cryptic algorithms, you are to blame instead).

Other keys like enforcing the use of good grammar and simplicity of the commenting language is also important too, but don’t let that stopping you from commenting your code if you are not fluent at the target language.

You are an awesome person for reading this. Why? because you have the passion to look the answer, to be a better developer, thus making your life and others easier to make reading codes and documentations an enjoyable experience.

Protect it, live it, love it, soon it is nothing for you, but a good habit.