ESTRUTURA DO REPOSITÓRIO

Olá pessoal!

Nesse post vou explicar sobre a estrutura de repositório que iremos utilizar:

NOPSIU:

Pasta criada no repositório da faculdade.Dentro da pasta NoPsiu existirão as pastas: Documentação, Library e Work:

DOCUMENTAÇÃO:
Devem ser inseridas todas as documentações referentes ao projeto.

LIBRARY
 Devem ser inseridos todos os arquivos externos necessários para compilar as aplicações(dll’s, frameworks, etc.).

WORK
Devem ser inseridos todos os arquivos necessários para compilar o projeto.

No nível seguinte existirão as pastas Branch, Tag e Trunk:

ü  Branch/Ramo

A pasta branch contém uma cópia de determinada revisão de trunk quando este estiver estável ou for necessário criar uma nova funcionalidade que posteriormente será mesclada de volta ao tronco ou até mesmo para criar outra linha de desenvolvimento independente do tronco.

ü  Tag

Normalmente utilizada para lançamentos de “releases”, a tag marca um ponto estável do desenvolvimento.

ü  Trunk

A pasta trunk é principal área de desenvolvimento. Todas as atualizações efetuadas dia-a-dia são armazenadas na pasta trunk. Geralmente contém os arquivos mais atuais do projeto, bem como as correções de bugs e os últimos recursos adicionados ao projeto.

E finalmente a estrutura do projeto:

TRUNK

ü  BD

Devem ser armazenados todos os arquivos referentes ao banco de dados(tabelas, procedures, modelos, etc.)

ü  BLL
Utilizada para os projetos de regras de negócio.

ü  Core

Utilizada para classes crosscuting (que são enxergadas em todas as camadas), como Util.cs

ü  Entidades

Contem elementos básicos, como interfaces, classes abstratas, enums, classes concretas seguindo POCO, etc.

ü  Gestao

Contem o projeto WinForms para a criação do backend.

ü  Mobile

Devem ser adicionados os arquivos utilizados para a aplicação mobile.

ü  NoPsiuTestes

Deve ser utilizada para o projeto de testes automatizados.

ü  Repositório

Utilizada para o projeto de comunicação com o Banco de Dados.

ü  Servico

Deve conter os projetos para disponibilização de serviços.

Padrões de Codificação

Olá pessoal!

Estou escrevendo este post para explicar sobre os padrões de codificação que iremos utilizar em nosso projeto.

O que é um padrão de codificação?

Um padrão de codificação é basicamente a definição de como será a formatação do código fonte e como serão nomeadas as variáveis, classes, funções, propriedades, etc. Existem diversos padrões utilizados no mercado e nenhum é melhor que o outro. O que importa é que uma vez escolhido um padrão para um projeto, deve-se segui-lo ate o final, não misturando vários padrões.

Cada linguagem possui um padrão recomendado, é importante segui-lo para manter o padrão com bibliotecas da linguagem e também para que outros desenvolvedores da linguagem possam ter familiaridade com seu código caso seja necessário dar manutenção no mesmo.

Principais padrões de codificação

Pascal Casing

O primeiro caracter de todas as palavras deve estar em letra maiúscula (UpperCase) e o restante dos caracteres em letra minúscula (LowerCase)

Ex.: NomeFuncionario

Camel Casing

O primeiro caracter de todas as palavras, com exceção da primeira, deve estar em letra maiúscula (UpperCase) e o restante dos caracteres em letra minúscula (LowerCase)

Ex.: nomeFuncionario

Notação Húngara

No inicio da palavra deve ser utilizado o prefixo do tipo da variável como “s” para String e “n” para int, em conjunto com o camel casing.

Ex.: sNomeFuncionario

Obs.: A notação húngara é utilizada para podermos identificar o tipo da variável. Atualmente ela não é recomendada, pois a maioria das IDE’s possuem maneiras mais fáceis para verificação dos tipos das variáveis.

Padrões do projeto

Agora vou explicar sobre os padrões utilizados em nosso projeto:

Pascal Case

No projeto utilizaremos pascal case nas seguintes situações:

    1.       Definição de classes

public class Funcionario

{

       ...

} 

     2.       Definição de métodos

public void CadastrarFuncionario(string nome)
{
      ...
}

    3.       Definição de Propriedades

Propriedades são atributos públicos, ou seja, podem ser acessados fora da classe através dos métodos Get e Set. A partir da versão 3.0 do .Net Framework, foram criadas as propriedades auto implementadas, onde esses métodos são criados automaticamente. Em nosso projeto utilizaremos como padrão as propriedades auto implementadas.

public NomeFuncionario { get; set; }

    4.       Definição de interfaces

Utilizar pascal case com o prefixo “I” para definir as interfaces

public interface IEntidade

{

       ...

}

  

Camel Case

Utilizaremos camel case nas situações seguintes:

    

    5.       Definição de atributos privados

private String nomeFuncionario;

    6.       Definição de parâmetros de métodos

public void CadastrarFuncionario(string nome)

{

       ...

}

Descrição de Nomes

    

    7.       Nomes Completos

Utilize sempre o nome completo para definir nomes de variáveis, métodos, classes, etc. Não utilize abreviações.

Certo:

public String NomeFuncionario;

public void CadastrarFuncionario(string nome)

{

       ...

}

Errado:

public String NmFun;

public void CadFun(string nome)

{

       ...

}

    8.       Não utilizar caracteres

Não utilizar apenas um caracter para definir o nome da variável

Certo:

private int index;

Errado

private int i;

Uma exceção para esta regra é na utilização de iterações em loops:

for ( int i = 0; i < count; i++ )

{

       ...

}

    9.       Não utilizar o underscore (“_”)

Não utilizar o underscore na definição de parâmetros, para diferenciar um atributo local de um parâmetro deve-se utilizar o “this.”.

Certo:

private String nome;

public Funcionario(string nome)

{

       this.nome = nome;

}

Errado:

private String nome;

public Funcionario(string _nome)

{

       nome = _nome;

}

    10.   Atributos boolean

Utilizar o prefixo “is” antes do nome da variável

public Boolean IsFinalizado{ get; set; }

  

    11.   Interface Gráfica

Para elementos de interface gráfica, deve se utilizar a seguinte tabela de prefixos como padrão. A notação deve ser camel case.

private Label lblNome;

Controle	Prefixo
Label	lbl
TextBox	txt
DataGrid	dtg
Button	btn
ImageButton	imb
Hyperlink	hlk
DropDownList	ddl
ListBox	lst
DataList	dtl
Repeater	rep
Checkbox	chk
CheckBoxList	cbl
RadioButton	rdo
RadioButtonList	rbl
Image	img
Panel	pnl
PlaceHolder	phd
Table	tbl
Validators	val

Referencias:

http://michaelsync.net/2008/02/29/c-30-tutorials-auto-implemented-properties-aka-automatic-properties acessado em 30/09/2012

http://pt.wikipedia.org/wiki/Nota%C3%A7%C3%A3o_h%C3%BAngara acessado em 30/09/2012

http://www.dotnetspider.com/tutorials/BestPractices.aspx acessado em 30/09/2012

http://www.1bit.com.br/content.1bit/weblog/programando_melhor_nomenclatura acessado em 30/09/2012

Ontem, 12/09, após a apresentação oficial de nossa proposta de projeto, o professor Ivan nos relatou problema com o feed do blog.
Depois de uma alteração na configuração, veremos se já está funcionando.

Projeto de Final de Curso - NoPSIU!

NoPSIU!

Num restaurante lotado a disputa para receber o atendimento de um garçom é tremenda.

Além do braço acenando, tentando chamar à atenção, frases como “Ô, garçom!”, “Hei, amigo!”, “Ô, meu chapa, por favor!” além do tradicional “psiu...psiuuuuu!” são bastante comuns.

Nossa intenção é acabar ou, pelo menos, minimizar o “psiu!” nos restaurantes.

Para tanto, nossa proposta para o projeto final é desenvolver uma aplicação para dispositivos móveis onde o cliente possa visualizar o cardápio do restaurante e efetuar seu pedido sem a necessidade da presença de um garçom, agilizando muito mais o atendimento.

Membros do grupo:

Fabiano Mendes
Gabriel Café
Rogério Norio Okawa
Sérgio Ferreira
Thomás Daniel Gerotti
Wesley Camargo