Há várias maneiras além de capturas de tela para incluir código em um artigo publicado no Microsoft Learn:
Elementos individuais (palavras) numa linha.
Eis um exemplo do estilo code.
Utilize o formato de código quando se referir a parâmetros e variáveis com nome num bloco de código próximo no seu texto. O formato de código também pode ser utilizado para propriedades, métodos, classes e palavras-chave de linguagem. Para obter mais informações, veja Elementos de código mais adiante neste artigo.
Blocos de código no ficheiro Markdown do artigo.
```csharp
public static void Log(string message)
{
_logger.LogInformation(message);
}
```
Utilize blocos de código inline quando for pouco prático apresentar código com referência a um ficheiro de código. Para obter mais informações, veja Blocos de código mais adiante neste artigo.
Blocos de código com referência a um ficheiro de código do repositório local.
Um "elemento de código" é uma palavra-chave, um nome de classe, um nome de propriedade, entre outros, que faz parte de uma linguagem de programação. Nem sempre é óbvio determinar o que se qualifica como código. Por exemplo, os nomes de pacotes do NuGet devem ser tratados como código. Em caso de dúvida, veja Diretrizes de formatação de texto.
Estilo de código inline
Para incluir um elemento de código no texto do artigo, rodeie-o com backticks (') para indicar o estilo do código.
O estilo de código inline não deve utilizar o formato de acentos graves triplos.
Markdown
Composto
Por padrão, o Entity Framework interpreta uma propriedade chamada 'Id' ou 'ClassnameID' como a chave primária.
Por predefinição, o Entity Framework interpreta uma propriedade com o nome Id ou ClassnameID como a chave primária.
Quando um artigo é localizado (traduzido para outros idiomas), o texto com o estilo de código não é traduzido. Se pretender evitar a tradução sem utilizar o estilo de código, veja Cadeias de carateres não traduzidas.
Estilo negrito
Alguns guias de estilo mais antigos especificam que o código inline deve estar a negrito. O negrito é uma opção que se pode utilizar quando o estilo de código é de tal forma intrusivo que compromete a legibilidade. Por exemplo, uma tabela Markdown que contenha maioritariamente elementos de código poderá parecer demasiado preenchida com estilos de código. Se optar por utilizar o estilo negrito, utilize cadeias de carateres não traduzidas para garantir que o seu código não está traduzido.
Ligações
Uma ligação para documentação de referência pode ser mais útil do que formato de código em alguns contextos. Se utilizar uma ligação, não aplique formato de código ao texto de ligação. Ao aplicar um estilo de código a uma ligação, pode tornar menos claro que o texto se trata de uma ligação.
Se utilizar uma ligação e referir o mesmo elemento mais tarde no mesmo contexto, as instâncias subsequentes devem utilizar formato de código em vez de ligações. Por exemplo:
The first reference to <xref:System.CommandLine> in this text is a link.
Subsequent references to `System.CommandLine` can be in code style.
Composto:
A primeira referência neste System.CommandLine texto é um link.
As referências subsequentes podem System.CommandLine ser em estilo de código.
Marcadores de Posição
Se desejar que o usuário substitua uma seção do código exibido por seus próprios valores, use o texto de espaço reservado marcado por colchetes angulares. Por exemplo:
az group delete -n <ResourceGroupName>
Você pode notar que os parênteses devem ser removidos ao substituir valores reais. O Microsoft Writing Style Guide pede itálico, que pode ser formatado dentro de um código embutido entre colchetes angulares:
<ResourceGroupName> é o grupo de recursos onde...
As chaves { } são desencorajadas para uso como espaços reservados sintáticos. Eles podem ser confundidos com a mesma notação usada em texto substituível, cadeias de caracteres de formato, interpolação de cadeia de caracteres, modelos de texto e construções de programação semelhantes.
Os nomes de espaços reservados podem ser separados por hífenes ("caso de kebab"), com sublinhados, ou não separados de todo (caso de Pascal). Caso de Kebab pode gerar erros de sintaxe e sublinhados podem entrar em conflito com sublinhado. Todas as letras maiúsculas podem entrar em conflito com constantes nomeadas em muitos idiomas, embora também possam chamar a atenção para o nome do espaço reservado.
<Resource-Group-Name> ou <ResourceGroupName>
Blocos de código
A sintaxe para incluir código num documento depende da localização do código:
Todos os métodos indicados na secção anterior resultam em blocos de código utilizáveis:
Pode copiar e colar.
São indexados por motores de busca.
São acessíveis aos leitores de ecrã.
Estes são apenas alguns dos motivos pelos quais as capturas de ecrã de IDE não são recomendadas como um método de incluir código num artigo. Utilize capturas de ecrã de IDE para código apenas se estiver a mostrar algo sobre o próprio IDE, como o IntelliSense. Não utilize capturas de ecrã apenas para mostrar colorização e realces.
Validação de código
Alguns repositórios implementaram processos que compilam automaticamente todos os exemplos de código para verificar a existência de erros. O repositório .NET faz isto. Para obter mais informações, veja Contribuir no repositório .NET.
Se estiver a incluir blocos de código de outro repositório, trabalhe com os proprietários numa estratégia de manutenção do código para que o seu código incluído não falhe ou fique desatualizado à medida que novas versões das bibliotecas que o código utiliza são enviadas.
Destacar
Normalmente, os fragmentos incluem mais código do que o que é preciso para contextualizar. Quando destaca as linhas chave e que se está a focar dentro do fragmento, está a contribui para a legibilidade, tal como neste exemplo:
Não pode destacar o código quando o inclui no ficheiro Markdown do artigo. Só resulta em fragmentos de código incluídos por referência a um ficheiro de código.
Barras de deslocamento horizontal
Divida as linhas compridas para evitar as barras de deslocamento horizontais. As barras de deslocamento nos blocos de código dificultam a leitura do mesmo. São especialmente problemáticas em blocos de código mais longos, onde pode ser impossível ver em simultâneo a barra de deslocamento e a linha que quer ler.
Uma boa prática para minimizar as barras de deslocamento horizontal nos blocos de código consiste em dividir linhas de código com mais de 85 carateres. No entanto, tenha em atenção que a presença ou ausência de uma barra de deslocamento não é o único critério de legibilidade. Se dividir uma linha antes dos 85 carateres prejudicar a legibilidade ou conveniência de copiar e colar, não hesite em exceder os 85.
Identifique claramente o código incorreto
Em alguns cenários, é útil apontar padrões de codificação que devem ser evitados, por exemplo:
Código que causará um erro de compilador se tentado.
Código que será compilado corretamente, mas não é recomendado.
Para estes cenários:
Explique o erro nos comentários de código e no texto do artigo.
Os leitores muitas vezes ignoram o texto do artigo e olham apenas para o código, por isso não é suficiente explicar o erro apenas no texto do artigo. Também não é suficiente explicar o erro apenas em comentários de código, porque os comentários de código não são localizados.
Considere comentar o código se ele causar um erro do compilador.
O código comentado não interromperá o sistema de integração contínua (CI) se o repositório do artigo tiver um agora ou implementar um no futuro.
Para obter um exemplo de como apresentar código que não é recomendado, consulte Exemplo de uso de runa: alterando maiúsculas e minúsculas. Neste exemplo, o conselho para evitá-lo é até mesmo incorporado no próprio código, como o nome do método C# é ConvertToUpperBadExample.
Blocos de código inline
Utilize blocos de código inline apenas quando for pouco prático apresentar código com referência a um ficheiro de código. Geralmente, o código inline é mais difícil de testar e manter atualizado em comparação com um ficheiro de código que faz parte de um projeto completo. O código inline pode omitir o contexto que poderia ajudar o programador a compreender e utilizar o código. Estas considerações aplicam-se principalmente a linguagens de programação. Os blocos de código inline também podem ser utilizados para saídas e entradas (como JSON), linguagens de consulta (como SQL) e linguagens de scripts (como PowerShell).
Há duas maneiras de indicar que uma seção de texto em um arquivo de artigo é um bloco de código: cercando-a em triplos ticks (''') ou recuando-a. A delimitação por barreiras é preferível, uma vez que lhe permite especificar a linguagem. Evite utilizar avanços porque é muito fácil cometer um erro e pode ser difícil para outro autor compreender a sua intenção quando precisa de editar o seu artigo.
Os indicadores de linguagem são posicionados imediatamente antes dos acentos graves triplos iniciais, conforme o exemplo a seguir:
O GitHub Flavored Markdown suporta a delimitação de blocos de código com tildes (~), bem como com backticks (').
O símbolo usado para abrir e fechar o bloco de código deve ser consistente dentro do mesmo bloco de código.
Se você usar uma palavra de idioma ou ambiente após os triplos backticks (''') que não é suportada, essa palavra aparecerá na barra de título da seção de código na página renderizada. Sempre que possível, utilize um indicador de ambiente ou linguagem nos seus blocos de código inline.
Nota
Se você copiar e colar o código de um documento do Word, certifique-se de que ele não tenha "aspas enroladas", que não são válidas no código. Se tiver, altere para aspas normais (' e "). Como alternativa, conte com o Learn Authoring Pack, recurso de substituição de cotações inteligentes.
Referências a fragmentos dentro do repositório
A forma preferível de incluir fragmentos de código para linguagens de programação em documentos é através de referência a um ficheiro de código. Este método dá-lhe a capacidade de realçar linhas de código e disponibiliza o contexto mais amplo do fragmento no GitHub para que os programadores possam utilizá-lo. Você pode incluir código usando o formato de dois pontos triplos (:::) manualmente ou no Visual Studio Code com a ajuda do Learn Authoring Pack.
No Visual Studio Code, prima Alt+M ou Opção+M e selecione Snippet (Fragmento).
Quando a opção Snippet (Fragmento) estiver selecionada, ser-lhe-á pedido para selecionar Full Search (Pesquisa Completa), Scoped Search (Pesquisa de Âmbito) ou Cross-Repository Reference (Referência Entre Repositórios). Para procurar localmente, selecione Full Search (Pesquisa Completa).
Introduza um termo de pesquisa para procurar o ficheiro. Quando encontrar o ficheiro, selecione-o.
Em seguida, selecione uma opção para determinar que linhas de código devem ser incluídas no fragmento. As opções são: ID, Range e None.
Com base na sua seleção no Passo 4, forneça um valor caso seja necessário.
Utilize apenas letras e carateres de sublinhado para o nome.
O exemplo apresenta a secção snippet_Create do ficheiro de código. O ficheiro de código deste exemplo tem etiquetas de fragmentos nos comentários no código C#:
// code excluded from the snippet
// <snippet_Create>
// code included in the snippet
// </snippet_Create>
// code excluded from the snippet
Trechos de código nomeados podem ser aninhados, conforme mostrado no exemplo a seguir:
// <Method>
public static void SomeMethod()
{
// <Line>
// Single line of code.
// </Line>
}
// </Method>
Quando o trecho de Method código é renderizado, as Line tags não são incluídas na saída renderizada.
Sempre que puder, crie uma referência para uma secção com nome em vez de especificar números de linha. As referências a números de linha são falíveis porque os ficheiros de código são inevitavelmente alterados de formas que alteram os números de linha.
Poderá não receber uma notificação a informar que ocorreram tais alterações. Eventualmente, o seu artigo começará a apresentar as linhas erradas e nem saberá que algo foi alterado.
O exemplo destaca as linhas 2 e 5, a contar do início do fragmento apresentado. Os números de linha a realçar não são contabilizados a partir do início do ficheiro de código. Por outras palavras, as linhas 3 e 6 do ficheiro de código estão realçadas.
Referências a fragmento fora do repositório
Se o ficheiro de código que pretende referenciar se encontrar num repositório diferente, tem de configurar o repositório de código como um repositório dependente. Quando o fizer, especifique um nome para o repositório. Posteriormente, esse nome atuará como um nome de pasta para fins de referência a código.
Por exemplo, o repositório de documentos é Azure/azure-docs e o repositório de código é Azure/azure-functions-durable-extension.
Na pasta raiz azure-docs, adicione a seguinte secção em .openpublishing.publish.config.json:
Agora, quando mencionar samples-durable-functions como se fosse uma pasta dentro de azure-docs, está efetivamente a referir-se à pasta raiz no repositório azure-functions-durable-extension.
Você pode incluir código usando o formato de dois pontos triplos (:::) manualmente ou no Visual Studio Code com a ajuda do Learn Authoring Pack.
No Visual Studio Code, prima Alt+M ou Opção+M e selecione Snippet (Fragmento).
Quando a opção Snippet (Fragmento) estiver selecionada, ser-lhe-á pedido para selecionar Full Search (Pesquisa Completa), Scoped Search (Pesquisa de Âmbito) ou Cross-Repository Reference (Referência Entre Repositórios). Para procurar entre repositórios, selecione Cross-Repository Reference (Referência Entre Repositórios).
Ser-lhe-á apresentada uma seleção dos repositórios presentes no .openpublishing.publish.config.json. Selecione um repositório.
Introduza um termo de pesquisa para procurar o ficheiro. Quando encontrar o ficheiro, selecione-o.
Em seguida, selecione uma opção para determinar que linhas de código devem ser incluídas no fragmento. As opções são: ID, Range e None.
Com base na sua seleção no Passo 5, forneça um valor.
A sua referência a um fragmento terá o seguinte aspeto:
No repositório azure-functions-durable-extension, esse ficheiro de código está na pasta samples/csx/shared. Conforme mencionado anteriormente, os números de linha de destaque são relativos ao início do fragmento e não ao início do ficheiro.
Nota
O nome atribuído ao repositório dependente é relativo à raiz do repositório principal, mas o til (~) refere-se à raiz do docset. A raiz docset é determinada por build_source_folder in .openpublishing.publish.config.json. O caminho para o fragmento no exemplo anterior funciona no repositório azure-docs porque build_source_folder se refere à raiz do repositório (.). Se build_source_folder fossem articles, o caminho iria começar com ~/../samples-durable-functions em vez de ~/samples-durable-functions.
Trechos em um caderno Jupyter
Você pode fazer referência a uma célula em um bloco de anotações Jupyter como um trecho de código. Para referenciar a célula:
Adicione metadados de célula ao bloco de anotações para as células que você deseja referenciar.
Configure o acesso ao repositório.
Use a sintaxe de trecho do bloco de anotações Jupyter em seu arquivo de marcação.
Adicionar metadados ao bloco de notas
Nomeie a célula adicionando metadados de célula no bloco de anotações Jupyter.
No Jupyter, você pode editar metadados de célula ativando primeiro a barra de ferramentas da célula: Exibir > Barra de Ferramentas de Célula > Editar Metadados.
Quando a barra de ferramentas da célula estiver ativada, selecione Editar metadados na célula que você deseja nomear.
Ou você pode editar metadados diretamente na estrutura JSON do bloco de anotações.
Nos metadados da célula, adicione um atributo "name":
"metadata": {"name": "<name>"},
Por exemplo:
"metadata": {"name": "workspace"},
Gorjeta
Você pode adicionar quaisquer outros metadados que desejar para ajudá-lo a rastrear onde a célula está sendo usada. Por exemplo:
Se o arquivo do bloco de anotações que você deseja referenciar estiver em um repositório diferente, configure o repositório de código como um repositório dependente.
Referência de sintaxe de trecho de bloco de anotações Jupyter
Assim que o seu bloco de notas contiver os metadados necessários, consulte-os no seu ficheiro de marcação. Use o que você adicionou ao bloco de anotações e o <cell-name-value> que você configurou <path> como seu repositório dependente.
```csharp-interactive
var aFriend = "Maria";
Console.WriteLine($"Hello {aFriend}");
```
renderiza como:
var aFriend = "Maria";
Console.WriteLine($"Hello {aFriend}");
Para ativar esta funcionalidade para um bloco de código particular, tem de utilizar um identificador de linguagem especial. As opções disponíveis são:
azurepowershell-interactive – ativa o Azure PowerShell Cloud Shell, tal como no exemplo anterior
azurecli-interactive – Ativa o Azure Cloud Shell
csharp-interactive – Ativa o C# REPL
No caso do Azure Cloud Shell e do PowerShell Cloud Shell, os utilizadores podem executar comandos apenas na sua própria conta do Azure.
Fragmentos de código incluídos por referência
Pode ativar o modo interativo para fragmentos de código incluídos por referência.
Para ativar esta funcionalidade para um bloco de código particular, tem de utilizar o atributo interactive. Os valores do atributo disponíveis são:
cloudshell-powershell – ativa o Azure PowerShell Cloud Shell, tal como no exemplo anterior
cloudshell-bash – Ativa o Azure Cloud Shell
try-dotnet – ativa o Try .NET
try-dotnet-class – ativa o Try .NET com scaffolding de classes
try-dotnet-method – ativa o Try .NET com scaffolding de métodos
No caso do Azure Cloud Shell e do PowerShell Cloud Shell, os utilizadores podem executar comandos apenas na sua própria conta do Azure.
Para a experiência do .NET Interactive, o conteúdo do seu bloco de código depende de qual das três experiências de scaffolding escolhe:
Sem andaimes (try-dotnet): O bloco de código deve representar um texto completo do programa. Por exemplo, o ficheiro Program.cs gerado por dotnet new console seria válido. Estes são mais úteis para mostrar um programa pequeno completo, incluindo as diretivas using necessárias. De momento, as instruções de nível superior não são suportadas.
Andaime de método (try-dotnet-method): O bloco de código deve representar o conteúdo de um método em um Main aplicativo de console. Pode assumir as diretivas using adicionadas pelo modelo dotnet new console. Esta definição é mais útil para fragmentos pequenos que demonstram uma funcionalidade.
Andaime de classe (try-dotnet-class): O bloco de código deve representar uma classe com um Main método como ponto de entrada do programa. Esta definição pode ser utilizada para demonstrar como os membros de uma classe interagem.
Esta sintaxe é uma extensão Markdown de bloco. Tem de ser usada numa linha própria.
<language> (opcional)
Linguagem do fragmento de código. Para obter mais informações, veja a secção Linguagens suportadas mais à frente neste artigo.
<path> (obrigatório)
O caminho relativo no sistema de ficheiros que indica o ficheiro do fragmento de código a referenciar.
<attribute> e <attribute-value> (opcionais)
Usados juntos para especificar como o código deve ser recuperado do arquivo e como ele deve ser exibido:
range: 1,3-5 Um intervalo de linhas. Este exemplo inclui as linhas 1, 3, 4 e 5.
id: Create A ID do trecho que precisa ser inserido do arquivo de código. Este valor não pode coexistir com o intervalo.
highlight: 2-4,6 Intervalo e/ou números de linhas que precisam ser destacados no trecho de código gerado. A numeração é relativa às linhas apresentadas (conforme especificado pelo intervalo ou ID), não ao ficheiro.
interactive: cloudshell-powershell, cloudshell-bash, try-dotnet, try-dotnet-class, try-dotnet-method O valor de cadeia determina que tipos de interatividade estão ativados.
Para obter detalhes sobre a representação de nomes de etiquetas nos ficheiros de origem dos fragmentos de código por linguagem, veja as diretrizes do DocFX (em inglês).
Idiomas suportados
O Learn Authoring Pack inclui um recurso para fornecer preenchimento de instrução e validação dos identificadores de idioma disponíveis para blocos de cerca de código.
O recurso Learn Authoring Pack, Dev Lang Completion usa o primeiro alias válido quando vários aliases estão disponíveis.
Próximos passos
Para obter informações sobre formatação de texto para tipos de conteúdos que não sejam código, veja Text formatting guidelines (Diretrizes de formatação de texto).
Utilize blocos de código com mais confiança, compreenda como afetam a visibilidade e a acessibilidade de construções de nível superior e inferior no seu código.