Skip to content

Latest commit

 

History

History
343 lines (260 loc) · 13.4 KB

README.md

File metadata and controls

343 lines (260 loc) · 13.4 KB

Algoritmos de Ordenação (Delphi)

Mostra visualmente os diversos algoritmos de ordenação, desenvolvido em Delphi.


Maintenance Build GitHub release (latest by date) GitHub Release Date Github repo age Github author

GitHub contributors GitHub last commit GitHub commit activity

GitHub issues GitHub closed issues GitHub pull requests GitHub closed pull requests GitHub forks GitHub stars GitHub All Releases

GitHub top language GitHub language count GitHub code size in bytes

GitHub



Índice

  1. Vídeos
  2. Sitemap
  3. Estrutura
  4. Workgroup
  5. Dependências
  6. Contribuir
  7. Checklist para Contribuir
  8. Créditos
  9. Licença
  10. Padronização de Código
  11. TODO
  12. Árvore do Projeto


Vídeos


Sitemap


Estrutura

  • app: Contém a compilação do(s) pacote(s) e tela de demonstração;
  • documentation: Contém a documentação do(s) pacote(s);
  • images: Contém as imagens usadas no(s) pacote(s);
  • modules: Contém os algoritmos de ordenação, cada módulo (pacote) corresponde à um algoritmo específico;
  • output: Contém os arquivos pré compilados usados pelo Delphi (.dcu);
  • project: Diretório com os projetos de cada pacote e visualizador;
  • src: Contém o fonte do visualizador e fontes comuns a todos;
  • vendor: Contém os pacotes de terceiros;

Workgroup

Deve-se manter a ordem de compilação do projeto como na imagem. Interfaces sempre no primeiro pacote SortInterfaces.bpl, e a visualização no executável Sorting.exe que será sempre o último pacote.

Workgroup


Dependências

  • Sem dependências até o momento.

Contribuir

  1. Faça um "fork" com base no master;
  2. Faça "commit" de suas alterações (Caso estiver resolvendo alguma "issue" não esqueça de na mensagem escrever "Fixed #numeroIssue");
  3. Faça "push" de seus commits;
  4. Solicite um "pull request" para o master do repositório principal.

Criando uma Issue

Para criar uma issue atente para o seguinte:

  • Selecionar o label adequado para a issue (esse label poderá vir a ser alterado, mas a não designação faz com que a issue fique perdida).

Label Issue

  • Selecionar o projeto Kanban, isso organizará o que está sendo feito e o que deverá ser feito.

Projeto Issue


Checklist para Contribuir

  • Testar as funcionalidades criadas / alteradas;
  • Marcar com "#" os issues concluídos, nos commits;
  • Readme (caso nescessário)
    • Número do build;
    • Alterar indice;
    • Alterar / adicionar forma de uso;
    • Incluir pacotes / classes / métodos / parâmetros nas formas de uso;
    • Alterar sitemap;
    • Alterar estrutura da aplicação;
    • Imagem atualizada do Workgroup;
    • Adicionar / Remover dependências (pacotes de terceiros);
    • Atualizar a documentação do fonte;
    • Remover / adicionar itens ao TODO;
    • Atualizar árvore do projeto;
  • Ao adicionar itens ao TODO, não esquecer de criar a "issue" correspondente;
    • Labels principais
      • bug: Correção de algum problema;
      • documentation: Alteração na documentação;
      • enhacement: Alteração de funcionalidade existente para melhorá-la;
      • feature: Nova funcionalidade;
    • Projeto
      • Kanban: Para melhor organizar o projeto;

Créditos

@bomrafinha



Padronização de Código

Versionamento

Para versionar esse repositório deve-se usar como base o versionamento para windows 32 bits do Sorting.exe, da forma que se segue:

Versionamento

onde:

  1. Versão principal, só muda quando o funcionamento básico do sistema altera de forma considerável;
  2. Quantidade de módulos funcionais do sistema (cada algoritmo de ordenação representa um módulo);
  3. Quantidade de funções públicas disponíveis no sistema;
  4. Versão de build do sistema auto-gerado pelo Delphi;
  5. Deve-se manter o build como auto incremento;

Para cada teste compilado com sucesso deve-se dar build no .exe para versionar (shift + F9).

Os releases do repositório serão feitos a cada vez que um módulo estiver 100% finalizado (considerando que um módulo equivale à um algoritmo de ordenação), ou quando um conserto muito relevante for realizado.


Padrões adotados no projeto

Para um melhor entendimento do projeto foi-se adotado alguns padrões que facilitam a identificação de cada estrutura usada. São, basicamente, o uso de camelCase, e PascalCase;

Variáveis de método

Variáveis locais devem ser camelCase.

Observar o espaçamento entre a declaração de variáveis e o inicio do método.

Variáveis de método

Variáveis privadas

A declaração de váriaveis privadas deve ocorrer sempre dentro dos modificadores de acesso.

Devem ser camelCase começando sempre com "f" seguido por seu nome.

Variáveis privadas

Propriedades

Propriedades devem usar PascalCase.

Devem ter exatamente o nome de sua variável privada e/ou metodo de acesso, eliminando apenas o prefixo (f, get, set).

Propriedades

Métodos

A declaração de métodos deve ocorrer sempre dentro dos modificadores de acesso.

Métodos devem ser camelCase.

Os parâmetros do método devem ser camelCase iniciando com "a".

Procurar, quando possível, usar prefixos get, set, eh, etc de acordo com a função do método e/ou seu retorno.

Ao serem chamados usar sempre parentesis em sua chamada, mesmo quando sem parâmetros. Ex: meuMetodo();

Métodos

Interfaces

Interfaces devem começar sempre com a letra "I" (maiúsculo), seguido por seu nome em PascalCase.

Interfaces

Classes

Classes devem começar sempre com a letra "T" (maiúsculo), seguido por seu nome em PascalCase.

Classes que não extendem nenhuma outra classes em específico devem extender TInterfacedObject.

Classes

Chamada de métodos em múltiplas linhas

Métodos com chamadas muito extensas devem ser chamados usando padrão de identação JSON.

Chamada de métodos em múltiplas linhas 01 Chamada de métodos em múltiplas linhas 02

Uso de blocos begin end

Estruturas que não se utilizam do bloco de abertura e fechamento de código, como ifs de uma linha, em um código muito extenso geralmente atrapalham na leitura do código para posteriores modificações. Por esse motivo todas as estruturas devem possuir o bloco de abertura e fechamento (begin .. end)

Uso de blocos begin end 01 Uso de blocos begin end 02

Identação

Modificadores de acesso devem ser declarados de forma a ficarem alinhados à declaração da classe.

Declaração de métodos, propriedades, construtores/destrutores, bem como o var da declaração de variáveis, devem estar alinhados.

Agrupar procedures e functions sem alterná-los.

Separar declações de variáveis, métodos, construtores, destrutores e propriedades com uma linha em branco, bem como deixar uma linha em branco antes da declaração de modificador de acesso, ou fim do bloco, exceto no primeiro modificador após a declaração da classes.

Identação

Chamada de métodos e variaveis internas da classe

Devem ser precedidas da palavra reservada Self, para facilitar a leitura do código.

Self

Palavras Reservadas

Dá-se preferência ao uso de iniciais minúsculas para palavras reservadas. Porém isso não é uma regra para o projeto tendo em vista que por serem reservadas a IDE às sinaliza, não atrapalhando, assim, a leitura do código.

Nomenclatura dos Arquivos

Deve-se nomear os arquivos começando-se com U_.

Para uma melhor localização dos arquivos no gerenciador de arquivos, e das unidades dentro do Delphi, devemos montar o nome dos arquivos compondo-os de seus módulos, submódulos, e função final, todos separados por ponto. Como segue na imagem a seguir:

Nomenclatura Arquivos

Um código bem padronizado é muito mais fácil de ler, mesmo por programadores que utilizam outras linguagens.


TODO

  • Documentação

    • Forma de Uso
    • Colocar algoritmos no TODO
  • Estrutura básica do código

  • Algoritmos

    • Bogo Sort
    • Merge Sort
    • Heap Sort
    • Shell Sort
    • Radix Sort
    • Gnome Sort
    • Counting Sort
    • Bucket Sort
    • Cocktail Sort
    • Tim Sort
    • Quick Sort

Árvore do Projeto

SortingAlgorithms
├── app
│   └── .gitkeep
├── documentation
│   └── images
│       ├── label_issue.png
│       ├── padrao_blocos_01.png
│       ├── padrao_blocos_02.png
│       ├── padrao_chamadas_01.png
│       ├── padrao_chamadas_02.png
│       ├── padrao_classes.png
│       ├── padrao_identacao_01.png
│       ├── padrao_interfaces.png
│       ├── padrao_metodos.png
│       ├── padrao_propriedades.png
│       ├── padrao_self_01.png
│       ├── padrao_variaveis_locais.png
│       ├── padrao_variaveis_privadas.png
│       ├── project_issue.png
│       ├── sitemap.png
│       ├── versionamento.png
│       └── workgroup.png
├── images
│   └── .gitkeep
├── modules
│   ├── BubbleSort
│   │   └── U_Sort.Bubble.pas
│   ├── CombSort
│   │   └── U_Sort.Comb.pas
│   ├── InsertionSort
│   │   └── U_Sort.Insertion.pas
│   └── SelectionSort
│       └── U_Sort.Selection.pas
├── output
│   └── .gitkeep
├── project
│   ├── BubbleSort.dpk
│   ├── BubbleSort.dproj
│   ├── CombSort.dpk
│   ├── CombSort.dproj
│   ├── InsertionSort.dpk
│   ├── InsertionSort.dproj
│   ├── SelectionSort.dpk
│   ├── SelectionSort.dproj
│   ├── Sorting.dpr
│   ├── Sorting.dproj
│   ├── SortingAlgorithms.groupproj
│   ├── SortInterfaces.dpk
│   └── SortInterfaces.dproj
├── src
│   ├── Sorting
│   │   ├── U_Sorting.Viewer.fmx
│   │   └── U_Sorting.Viewer.pas
│   └── SortInterfaces
│       ├── U_Sort.DTO.Retangle.pas
│       ├── U_SortClass.pas
│       └── U_SortInterface.pas
├── vendor
│   └── .gitkeep
├── .gitattributes
├── .gitignore
├── LICENSE
└── README.md