It’s an application that’s running and had been allocated memory.

A process is an instance of a running application. An application is an executable on the hard drive or network. There can be numerous processes launched of the same application (5 copies of Word running), but 1 process can run just 1 application. 

This is the code, which you will use for stop Services using VBS Script

Function StopServices
 Dim objWMIService,colItems,ObjItem,chkServiceStatus,RetVal
 Set objWMIService = GetObject("winmgmts:\\" & "." & "\root\cimv2")
 Set colItems = objWMIService.ExecQuery("Select * from Win32_Service where name='" & strServiceName & "'",,48)
 For Each ObjItem in colItems
  If (InStr (1,objItem.DisplayName,strServiceName,1) > 0) then
   chkServiceStatus=ObjItem.State
  end if
 Next

 If(ucase(chkServiceStatus)="RUNNING") THEN
  RetVal = goShell.Run("%windir%\system32\sc.exe Stop """ & strServiceName & """ >> " & gcsLogFile,0,True)
   Do Until(Ucase(ServiceStatus)="STOPPED")
    Set colItems = objWMIService.ExecQuery("Select * from Win32_Service where name='" & strServiceName & "'",,48)
    For Each ObjItem in colItems
     If (InStr (1,objItem.DisplayName,strServiceName,1) > 0) then
      ServiceStatus=ObjItem.State
     end if
    Next 
   Loop 
 End If

 
End Function

Pascal casing means that the first letter of each word in a name is capitalized: EmployeeSalary, OrderDetails, PassengerName.

The scope of a variable is the region of code from which the variable can be accessed. In general, the scope is determined by the following rules:

• A field (also known as a member variable) of a class is in scope for as long as its containing class is in scope (this is the same as for C++, Java, and VB).
• local variable is in scope until a closing brace indicates the end of the block statement or method in which it was declared.

• A local variable that is declared in a for, while, or similar statement is in scope in the body of that loop.

An assembly is the logical unit that contains compiled code targeted at the .NET Framework.

An assembly is completely self-describing, and is a logical rather than a physical unit, which means that it can be stored across more than one file (indeed dynamic assemblies are stored in memory, not on file at all). If an assembly is stored in more than one file, then there will be one main file that contains the entry point and describes the other files in the assembly.

Note that the same assembly structure is used for both executable code and library code. The only real difference is that an executable assembly contains a main program entry point, whereas a library assembly doesn’t.

Assemblies come in two types: shared and private assemblies.

Private Assembly :
------------------
Private assemblies are the simplest type. They normally ship with software and are intended to be used only with that software.

The system guarantees that private assemblies will not be used by other software, because an application may only load private assemblies that are located in the same folder that the main executable is loaded in, or in a subfolder of it.

Shared Assembly :
-----------------
Shared assemblies are intended to be common libraries that any other application can use. Because any other software can access a shared assembly, more precautions need to be taken against the following risks:

•  Name collisions, where another company’s shared assembly implements types that have the same names as those in your shared assembly. Because client code can theoretically have access to both assemblies simultaneously, this could be a serious problem.
  
• The risk of an assembly being overwritten by a different version of the same assembly—the new version being incompatible with some existing client code.

Difference between DataGrid and Grid View is given below:-

Datagrid..
1.Code requires to handle the SortCommand event and rebind grid required.
2.Code requires to handle the PageIndexChanged.
3.Need extensive code for update operation on data.
4.When compared to gridview less events supported.

Grid View : ..
1.No code required.
2.No code required for PageIndexChanged.
3.Needs little code for update operation.
4.GridView supports events fired before and after database updates

Here are several techniques for achieving good coding practices that are less heavy-handed than laying down rigid coding standards:

Assign two people to every part of the project

If two people have to work on each line of code, you’ll guarantee that at least two people think it works and is readable. The mechanisms for teaming two people can range from pair programming to mentor-trainee pairs to buddy- system reviews.

Review every line of code

A code review typically involves the programmer and at least two reviewers.  That means that at least three people read every line of code. Another name for  peer review is “peer pressure.” In addition to providing a safety net in case the original programmer leaves the project, reviews improve code quality because the programmer knows that the code will be read by others. Even if your shop hasn’t created explicit coding standards, reviews provide a subtle way of moving toward a group coding standard—decisions are made by the group during reviews, and, over time, the group will derive its own standards.

Require code sign-offs

In other fields, technical drawings are approved and signed by the managing  engineer. The signature means that to the best of the engineer’s knowledge, the  drawings are technically competent and error-free. Some companies treat code the same way. Before code is considered to be complete, senior technical personnel must sign the code listing.

Route good code examples for review

A big part of good management is communicating your objectives clearly. One way to communicate your objectives is to circulate good code to your programmers or post it for public display. In doing so, you provide a clear example of the quality you’re aiming for. Similarly, a coding-standards manual can consist mainly of a set of “best code listings.” Identifying certain listings as “best” sets an example for others to follow. Such a manual is easier to update than an English-language standards manual and effortlessly presents subtleties in coding style that are hard to capture point by point in prose descriptions.

Emphasize that code listings are public assets

Programmers sometimes feel that the code they’ve written is “their code,” as if it were private property. Although it is the result of their work, code is part of the project and should be freely available to anyone else on the project that needs it. It should be seen by others during reviews and maintenance, even if at no other time.

One of the most successful projects ever reported developed 83,000 lines of code in 11 work-years of effort. Only one error that resulted in system failure was detected in the first 13 months of operation. This accomplishment is even more dramatic when you realize that the project was completed in the late 1960s, without online compilation or interactive debugging. Productivity on the project, 7500 lines of code per work-year in the late 1960s, is still impressive by today’s standards. The chief programmer on the project reported that one key to the project’s success was the identification of all computer runs (erroneous and otherwise) as public rather than private assets (Baker and Mills 1973). This idea  has extended into modern contexts including Extreme Programming’s idea of collective ownership (Beck 2000), as well as in other contexts.

Reward good code

Use your organization’s reward system to reinforce good coding practices. Keep these considerations in mind as you develop your reinforcement system:  

• The reward should be something that the programmer wants. (Many programmers find “attaboy” rewards distasteful, especially when they come from nontechnical managers.)
• Code that receives an award should be exceptionally good. If you give an award to a programmer everyone else knows does bad work, you look like Charlie Chaplin trying to run a cake factory. It doesn’t matter that the programmer has a cooperative attitude or always comes to work on time. You lose credibility if your reward doesn’t match the technical merits of the situation. If you’re not technically skilled enough to make the good-code judgment, don’t! Don’t make the award at all, or let your team choose the recipient.

One easy standard

If you’re managing a programming project and you have a programming background, an easy and effective technique for eliciting good work is to say “I  must be able to read and understand any code written for the project.” That the manager isn’t the hottest technical hotshot can be an advantage in that it may discourage “clever” or tricky code.