O que é o IRIS Code Insights

Antes de alterar uma classe do InterSystems IRIS, quase sempre vem a mesma pergunta: o que este código faz, quem o chama e onde ele pode quebrar? O IRIS Code Insights lê classes e rotinas ObjectScript e responde com três visões: achados ordenados por gravidade, o fluxograma de cada método e um mapa de quem chama quem. ^[1]

É um único arquivo HTML, sem instalação, sem conta e sem servidor.

Abrir o IRIS Code Insights →

Como o app trata o seu código

• Nada sai do seu computador. O arquivo bloqueia conexões de rede, e a leitura acontece no navegador.
• O código não fica guardado. Ao fechar a página, a análise some. O app só guarda o idioma e o tema.

Como levar o código ao app

O app aceita quatro formatos. Abra vários arquivos juntos: só assim ele consegue ligar uma chamada de uma classe ao método de outra.

Três jeitos de obter os arquivos

1. VS Code: com a extensão InterSystems ObjectScript, use o comando ObjectScript: Export Code from Server. Por padrão, os arquivos vão para a pasta src do workspace. ^[2]
2. Terminal do IRIS: o método Export da classe %SYSTEM.OBJ gera um XML com os itens pedidos, como classes e rotinas. ^[3]

Do $SYSTEM.OBJ.Export("Demo.*.cls","/tmp/demo.xml")

3. Colar: em Colar código, cole uma classe, uma rotina ou um XML. O nome do arquivo é opcional: sem ele, o app reconhece o tipo pelo conteúdo.

Roteiro: analisando o exemplo

Use o exemplo do próprio app: quatro arquivos fictícios, escritos para mostrar os achados. Há uma classe persistente de pedidos, uma API REST, um business service e uma rotina antiga. O que segue é exatamente o que você verá.

1. Abra o exemplo e leia os indicadores

1. Abra o app e clique em Ver um exemplo.
2. Confira o topo: 4 arquivos, 3 classes e 1 rotina, 15 métodos e rótulos, 197 linhas, complexidade média 2,3 (máxima 6), 60% dos métodos documentados e 3 achados críticos, com 11 de atenção.
3. Os filtros mostram 18 tipos de achado: 3 críticos, 8 de atenção e 7 de informação.

2. Vá do achado à linha

1. No achado Kill apaga uma global inteira, clique em Ver onde (1).
2. Clique em Order.Purge. A aba Código abre na linha 85, destacada: Kill ^DemoAudit.
3. Repare na linha 79: Kill ^DemoAudit(id) apaga só um nó e não gera achado. A diferença é o subscrito.

3. Leia o fluxo de um método

1. Abra a aba Fluxo e escolha Pay, na lista à esquerda.
2. O corpo está dentro de uma caixa Try, ligada à caixa Catch ex por uma seta tracejada vermelha: o caminho do erro.
3. O losango order.Status '= "NEW" ? leva a um Quit com borda vermelha e a nota sai do bloco atual.

Por que a borda vermelha? Segundo a documentação, um Quit sem argumento dentro de um Try leva a execução para a primeira linha depois do Catch, e não para fora do método. ^[4] Aqui a linha seguinte é Quit sc, então o efeito é o esperado. Mas, se alguém incluir código depois do Catch, ele também vai rodar para pedidos que não são novos. Return deixaria a intenção explícita. ^[6]

No mesmo método aparecem mais três achados: Do order.%Save() descarta o %Status, o &sql não confere SQLCODE e o TStart não tem TRollback no Catch.

4. Veja quem chama quem

1. Abra a aba Dependências e clique em Métodos.
2. Clique no nó PayOrder. O caminho fica em destaque: a rota POST /orders/:id/pay chega a ele, e ele chama Notify, Pay e Sync.Send.

5. Confira os dados usados

A aba Dados mostra duas tabelas SQL e quatro globais. A global ^DemoAudit é lida, gravada, apagada com Kill e travada com Lock, em 8 usos. A rota REST e a mensagem para Demo.ERP.Operation também aparecem. Essa classe de destino não está nos arquivos.

6. Gere o relatório

1. Clique em Relatório.
2. Revise o texto e use Copiar ou Baixar .md.

Resultado: em poucos minutos você sabe por onde começar. Há uma senha no código, um SQL vulnerável a injeção e um Kill que apaga a auditoria inteira. Também já sabe quais métodos e tabelas cada correção afeta.

Como ler os insights

Cada achado é uma regra simples sobre o texto do código, e estas são as condições exatas. Um achado diz onde olhar, não que há um defeito.

Crítico

Atenção

Informação

• %ResultSet está obsoleto: a referência de classes marca %Library.ResultSet como obsoleta e indica %SQL.Statement para SQL dinâmico. A classe continua funcionando. ^[11]
• $ZTrap ou $ETrap, Goto, privado sem uso nos arquivos, método sem documentação ///, endereço ou caminho fixo (URL, IP ou pasta) e classe que acessa global direto.
• Chamada recursiva: sem condição de parada, as chamadas se acumulam até o erro <FRAMESTACK>, que indica chamadas aninhadas demais. ^[12]
• Trecho que o app não entendeu: o fluxograma e os achados daquele membro podem estar incompletos.

Indicadores e complexidade

A complexidade segue a ideia de McCabe: quantos caminhos independentes existem no método. ^[13] O app faz uma aproximação: 1, mais cada If, ElseIf, laço, Catch e pós-condicional. Serve para comparar métodos entre si. "Métodos documentados" conta os métodos de classe com comentário ///. Abaixo da lista, Verificações sem achados mostra o que foi procurado e não encontrado.

Fluxo

A aba Fluxo desenha um método ou rótulo de cada vez, a partir dos comandos do código. Escolha o método na lista: o número ao lado do nome é a complexidade. Os métodos com mais caminhos ficam com o número em laranja ou vermelho.

• Agrupar comandos simples junta comandos seguidos como Set, Kill e New em um só bloco. Desmarque para ver um bloco por comando.
• Clique em um bloco para ver o comando inteiro, a linha e os achados. Ver código abre a linha. Dois cliques em uma chamada abrem o fluxo do método chamado.
• Arraste o fundo para mover, use os botões de zoom ou Ajustar, e Baixar SVG para salvar a figura.
• Abaixo do desenho, Detalhes do membro traz a declaração, a documentação, quem ele chama, quem o chama e os dados que usa.

Dependências

A aba Dependências mostra o mapa de quem chama quem. As colunas seguem a direção das chamadas: quem chama fica à esquerda. Quanto mais grossa a linha, mais chamadas.

• Classes junta tudo por classe ou rotina e mostra a herança em linha tracejada roxa. Métodos mostra cada método, as rotas REST que chegam a ele e os destinos de mensagens.
• Externos, Tabelas e Globais ligam e desligam esses nós. "Fora dos arquivos" é uma classe ou rotina citada que você não carregou.
• Uma linha que volta para a esquerda, em traço curto, fecha um ciclo de chamadas.
• Clique em um nó para destacar as ligações dele. O painel à direita lista o que sai e o que chega, com atalhos para o fluxo e o código.

Membros, Dados e Código

• Membros: a tabela de todos os membros, com tipo, linhas, complexidade, aninhamento, documentação e chamadas. Clique no título de uma coluna para ordenar e use o filtro e o tipo para reduzir a lista.
• Dados: as tabelas SQL, com as operações e a forma (&sql, SQL dinâmico ou Query da classe), e as globais, com o tipo de acesso: leitura, escrita, Kill ou Lock. A classe é ligada à tabela pelo nome SQL padrão: o pacote com _ no lugar do ponto, mais o nome da classe, ou o SqlTableName. As rotas REST vêm do XData UrlMap, e as mensagens, de SendRequestSync, SendRequestAsync e dos <call target> de uma BPL.
• Código: o arquivo com destaque de sintaxe. Escolha o arquivo, digite o número em linha e clique em Ir.
• Busca: o campo no topo encontra classes, métodos e rótulos em todos os arquivos.

Relatório e privacidade

Relatório gera um texto em Markdown com o resumo, os achados, os locais com o trecho do código e os métodos mais complexos, para anexar a um chamado, a uma revisão de código ou a uma wiki.

Novo volta à tela inicial e tira a análise da memória. Os arquivos no seu computador não mudam.

Prompts de IA

O app mostra onde olhar. Ainda falta entender o porquê, decidir a correção e explicá-la para a equipe. Uma IA ajuda nessas três tarefas, mas também erra com segurança: inventa métodos de sistema, confunde Quit com Return e propõe código que não compila. Trate a resposta como rascunho de um colega apressado. Para escrever prompts melhores, veja o tutorial de prompts.

Antes de colar: código é propriedade da empresa e pode trazer senhas, endereços e regras de negócio. O app não envia nada para a rede, mas o serviço de IA recebe tudo o que você colar nele. Retire os segredos que o app apontou, troque nomes de clientes e siga a política da sua organização para uso de IA.

Troque os trechos entre colchetes e cole na ferramenta de IA que você usa. Cada prompt funciona sozinho.

1. Priorizar os achados

Em Relatório, use Copiar, revise o texto e cole no fim do prompt.

Você é um desenvolvedor experiente em InterSystems IRIS e ObjectScript.
Abaixo está o relatório de uma ferramenta que lê o código sem compilar.

Contexto: [o que o sistema faz e o que você precisa mudar]

Com base só no relatório:
1. Ordene os achados pelo risco real para este contexto e diga por quê.
2. Aponte os que podem ser falsos positivos e o que conferir no código para decidir.
3. Sugira a ordem de correção, agrupando o que pode ir na mesma mudança.
4. Separe o que está no relatório do que é suposição sua.

Não invente classes, métodos nem comportamentos do IRIS. Se faltar informação, diga qual.

Relatório:
[cole o relatório]

2. Explicar um método

Na aba Fluxo, use Ver código e copie o método. Em Detalhes do membro, copie as listas Chama e Chamado por.

Explique o método ObjectScript abaixo para alguém que vai mantê-lo.

Classe: [nome da classe e o que ela representa]
Quem chama este método: [lista]
O que ele chama: [lista]

Código:
[cole o método]

Responda:
1. O que o método faz, em poucas frases.
2. Os caminhos possíveis, incluindo erros e saídas antecipadas.
3. O que ele lê e grava: propriedades, globais, tabelas e transações.
4. Pontos frágeis, citando a linha.

Lembre que Quit sem argumento dentro de Try sai só do bloco Try. Se não souber o que um método chamado faz, diga, em vez de supor.

3. Corrigir um achado

Copie o nome e a explicação do achado no app e o trecho de código ao redor da linha. Peça a menor mudança possível.

A ferramenta apontou este achado em um código ObjectScript do InterSystems IRIS:

Achado: [nome e explicação do achado]
Linha: [número]

Trecho:
[cole o método ou as linhas ao redor]

1. Confirme se o achado procede neste trecho e explique por quê.
2. Proponha a menor correção possível, mostrando o código antes e depois.
3. Diga o que muda no comportamento e o que pode quebrar em quem chama.
4. Diga como testar a correção.

Use só recursos que você sabe que existem no IRIS. Se não tiver certeza da sintaxe, avise.

4. Quebrar um método complexo

Use os métodos do cartão Métodos mais complexos. Peça para manter o comportamento, porque trocar Quit por Return pode mudar o fluxo. ^{[5] [6]}

O método ObjectScript abaixo tem complexidade [número] e [número] linhas.

[cole o método]

Proponha uma reorganização que:
1. Mantenha exatamente o mesmo comportamento, inclusive o retorno de %Status e as transações.
2. Extraia partes com propósito próprio para métodos privados com nomes claros.
3. Use Return quando a intenção for sair do método, e explique cada troca de Quit por Return.
4. Liste os casos de teste que provam que nada mudou.

Mostre o código completo. Não renomeie métodos públicos nem mude a assinatura.

5. Documentar uma classe

Útil para o achado Método sem documentação. Confira cada frase contra o código: a IA pode descrever o que o nome sugere, e não o que o código faz.

Escreva comentários /// para a classe ObjectScript abaixo, no estilo da referência de classes do IRIS.

[cole a classe]

Para a classe e para cada método:
1. Uma frase sobre o que faz.
2. Os argumentos e o retorno.
3. Efeitos colaterais: globais, tabelas, transações e Lock.

Escreva em [idioma]. Descreva só o que o código mostra. Quando não der para saber, escreva "verificar" em vez de supor.

6. Planejar testes

Peça casos de teste a partir do fluxograma: cada losango tem dois lados para cobrir.

Quero testar o método ObjectScript abaixo antes de alterá-lo.

[cole o método]

Formato de teste usado pela equipe: [ex.: %UnitTest.TestCase, ou descreva]

1. Liste os caminhos do método e um caso de teste para cada um.
2. Inclua os casos de erro: %Status de erro, exceção, SQLCODE diferente de 0.
3. Diga quais dados precisam existir antes e como limpá-los depois.
4. Escreva o código dos testes.

Não use métodos de asserção que você não tem certeza de que existem. Se precisar de um, pergunte.

7. Modernizar código antigo

Serve para $ZTrap, %ResultSet e a sintaxe com pontos. A referência de classes indica %SQL.Statement no lugar de %ResultSet. ^[11]

Modernize o código ObjectScript abaixo, sem mudar o que ele faz.

[cole o código]

Troque, quando houver:
1. $ZTrap ou $ETrap por Try/Catch.
2. %ResultSet por %SQL.Statement, com parâmetros ? no lugar de concatenação.
3. Sintaxe com pontos e If de linha por blocos com chaves.

Para cada troca, mostre antes e depois e explique a diferença de comportamento, se houver. Aponte o que precisa ser testado com cuidado.

8. Descrever a mudança para revisão

Use depois de corrigir: a IA organiza o texto, e você confere se cada afirmação é verdadeira.

Escreva a descrição de uma revisão de código para a mudança abaixo.

Problema encontrado: [achado e local]
O que foi mudado: [resumo ou diff]
Como foi testado: [descreva]

Estrutura:
1. Resumo em duas frases.
2. Motivo, com o achado e a linha.
3. O que muda para quem usa o código.
4. Riscos e como reverter.
5. O que o revisor deve olhar com atenção.

Não acrescente testes, números ou garantias que não estão aqui.

Como conferir a resposta

Erros comuns e limitações

Erros de leitura

• Tratar achado como defeito. Um Kill ^Global pode ser exatamente o que o método deve fazer. Confirme no código.
• Analisar uma classe sozinha. Sem as superclasses e as classes chamadas, muitas ligações aparecem como "Fora dos arquivos".
• Procurar no XML a linha citada. Na exportação XML, as linhas são as do texto convertido, na aba Código.
• Achar que complexidade baixa é código certo. Ela mede caminhos, não correção.

Limitações

• Leitura sem compilar. O app não expande macros, não resolve herança fora dos arquivos e pode errar em construções raras.
• Só código de exemplo. O app foi testado com o exemplo fictício e com trechos escritos para o teste, não com código de produção.
• Outras linguagens. Métodos em Python ou outra linguagem não têm fluxograma. O app conta as linhas e as chamadas iris.cls().
• Tamanho. Arquivos acima de 30 MB são ignorados. O mapa mostra até 180 nós, e a tabela de membros, até 1.500 linhas.
• Navegadores. Testado no Chromium. Firefox, Safari e celulares reais não foram testados.

Revisão rápida

Tente responder antes de abrir cada pergunta.

Referências

1. Giovani Perotto Mesquita, “IRIS Code Insights”, app em um único arquivo HTML, giovanipm.github.io/iris-code-insights.html.
2. InterSystems, fluxo de trabalho no cliente com a extensão ObjectScript para VS Code, comando Export Code from Server, documentação, consultado em 02/11/2026, docs.intersystems.com.
3. InterSystems, classe %SYSTEM.OBJ, método Export, referência de classes, documentação, consultado em 02/11/2026, docs.intersystems.com.
4. InterSystems, comando TRY, seção sobre QUIT e RETURN, referência de ObjectScript, documentação, consultado em 02/11/2026, docs.intersystems.com.
5. InterSystems, comando QUIT, referência de ObjectScript, documentação, consultado em 02/11/2026, docs.intersystems.com.
6. InterSystems, comando RETURN, referência de ObjectScript, documentação, consultado em 02/11/2026, docs.intersystems.com.
7. InterSystems, SQL dinâmico, parâmetros de entrada com ?, guia de SQL, documentação, consultado em 02/11/2026, docs.intersystems.com.
8. InterSystems, valores de SQLCODE, referência de SQL, documentação, consultado em 02/11/2026, docs.intersystems.com.
9. InterSystems, comando TROLLBACK e $TLEVEL, referência de ObjectScript, documentação, consultado em 02/11/2026, docs.intersystems.com.
10. InterSystems, comando LOCK, tempo limite, referência de ObjectScript, documentação, consultado em 02/11/2026, docs.intersystems.com.
11. InterSystems, classe %Library.ResultSet, marcada como obsoleta, referência de classes, documentação, consultado em 02/11/2026, docs.intersystems.com.
12. InterSystems, mensagens de erro do sistema, <FRAMESTACK>, documentação, consultado em 02/11/2026, docs.intersystems.com.
13. Thomas J. McCabe, “A Complexity Measure”, IEEE Transactions on Software Engineering, SE-2(4), 1976, p. 308–320, doi.org/10.1109/TSE.1976.233837.

What IRIS Code Insights is

Before you change an InterSystems IRIS class, the same questions almost always come up: what does this code do, who calls it and where can it break? IRIS Code Insights reads ObjectScript classes and routines and answers with three views: findings ordered by severity, a flowchart of each method and a map of who calls whom. ^[1]

It is a single HTML file, with no installation, no account and no server.

Open IRIS Code Insights →

How the app handles your code

• Nothing leaves your computer. The file blocks network connections, and reading happens in the browser.
• The code is not stored. When you close the page, the analysis is gone. The app only saves the language and the theme.

How to bring the code into the app

The app accepts four formats. Open several files together: only then can it link a call in one class to the method of another.

Three ways to get the files

1. VS Code: with the InterSystems ObjectScript extension, use the ObjectScript: Export Code from Server command. By default, the files go to the src folder of the workspace. ^[2]
2. IRIS Terminal: the Export method of the %SYSTEM.OBJ class creates an XML file with the requested items, such as classes and routines. ^[3]

Do $SYSTEM.OBJ.Export("Demo.*.cls","/tmp/demo.xml")

3. Paste: in Paste code, paste a class, a routine or an XML export. The file name is optional: without it, the app recognizes the type from the content.

Walkthrough: analyzing the sample

Use the app's own sample: four made-up files, written to show the findings. There is a persistent order class, a REST API, a business service and an old routine. What follows is exactly what you will see.

1. Open the sample and read the indicators

1. Open the app and click See a sample.
2. Check the top: 4 files, 3 classes and 1 routine, 15 methods and labels, 197 lines, average complexity 2.3 (maximum 6), 60% of methods documented and 3 critical findings, with 11 needing attention.
3. The filters show 18 kinds of finding: 3 critical, 8 attention and 7 information.

2. Go from the finding to the line

1. In the finding Kill erases an entire global, click See where (1).
2. Click Order.Purge. The Code tab opens at line 85, highlighted: Kill ^DemoAudit.
3. Look at line 79: Kill ^DemoAudit(id) erases only one node and does not create a finding. The difference is the subscript.

3. Read the flow of a method

1. Open the Flow tab and choose Pay in the list on the left.
2. The body is inside a Try box, linked to the Catch ex box by a red dashed arrow: the error path.
3. The diamond order.Status '= "NEW" ? leads to a Quit with a red border and the note leaves the current block.

Why the red border? According to the documentation, an argumentless Quit inside a Try moves execution to the first line after the Catch, not out of the method. ^[4] Here the next line is Quit sc, so the effect is the expected one. But if someone adds code after the Catch, it will also run for orders that are not new. Return would make the intent explicit. ^[6]

The same method has three more findings: Do order.%Save() throws away the %Status, the &sql does not check SQLCODE and the TStart has no TRollback in the Catch.

4. See who calls whom

1. Open the Dependencies tab and click Methods.
2. Click the PayOrder node. Its path is highlighted: the POST /orders/:id/pay route reaches it, and it calls Notify, Pay and Sync.Send.

5. Check the data used

The Data tab shows two SQL tables and four globals. The global ^DemoAudit is read, written, erased with Kill and locked with Lock, in 8 uses. The REST route and the message to Demo.ERP.Operation also show up. That target class is not in the files.

6. Create the report

1. Click Report.
2. Review the text and use Copy or Download .md.

Result: in a few minutes you know where to start. There is a password in the code, a SQL statement open to injection and a Kill that erases the whole audit trail. You also know which methods and tables each fix affects.

How to read the insights

Each finding is a simple rule about the text of the code, and these are the exact conditions. A finding tells you where to look, not that there is a defect.

Critical

Attention

Information

• %ResultSet is deprecated: the class reference marks %Library.ResultSet as deprecated and points to %SQL.Statement for dynamic SQL. The class still works. ^[11]
• $ZTrap or $ETrap, Goto, private and unused in the files, method without /// documentation, fixed address or path (URL, IP or folder) and class that accesses a global directly.
• Recursive call: without a stop condition, calls pile up until the <FRAMESTACK> error, which means too many nested calls. ^[12]
• Part the app did not understand: the flowchart and the findings of that member may be incomplete.

Indicators and complexity

Complexity follows McCabe's idea: how many independent paths a method has. ^[13] The app uses an approximation: 1, plus each If, ElseIf, loop, Catch and postconditional. It is useful for comparing methods with each other. "Documented methods" counts class methods with a /// comment. Below the list, Checks with no findings shows what was looked for and not found.

Flow

The Flow tab draws one method or label at a time, from the commands in the code. Choose the method in the list: the number next to the name is its complexity. Methods with more paths show the number in orange or red.

• Group simple commands joins consecutive commands such as Set, Kill and New into one block. Clear it to see one block per command.
• Click a block to see the whole command, the line and the findings. See code opens the line. Double-click a call to open the flow of the called method.
• Drag the background to move, use the zoom buttons or Fit, and Download SVG to save the picture.
• Below the drawing, Member details shows the declaration, the documentation, what it calls, who calls it and the data it uses.

Dependencies

The Dependencies tab shows the map of who calls whom. The columns follow the direction of the calls: callers are on the left. The thicker the line, the more calls.

• Classes groups everything by class or routine and shows inheritance as a purple dashed line. Methods shows each method, the REST routes that reach it and the message targets.
• External, Tables and Globals turn those nodes on and off. "Outside the files" is a class or routine that is cited but that you did not load.
• A line that goes back to the left, with short dashes, closes a cycle of calls.
• Click a node to highlight its links. The panel on the right lists what goes out and what comes in, with shortcuts to the flow and the code.

Members, Data and Code

• Members: the table of all members, with type, lines, complexity, nesting, documentation and calls. Click a column title to sort, and use the filter and the type to narrow the list.
• Data: the SQL tables, with the operations and the form (&sql, dynamic SQL or class Query), and the globals, with the kind of access: read, write, Kill or Lock. The class is linked to the table by the default SQL name: the package with _ instead of the dot, plus the class name, or the SqlTableName. REST routes come from XData UrlMap, and messages from SendRequestSync, SendRequestAsync and the <call target> elements of a BPL.
• Code: the file with syntax highlighting. Choose the file, type the number in line and click Go.
• Search: the field at the top finds classes, methods and labels in all files.

Report and privacy

Report creates a Markdown text with the summary, the findings, the places with the code excerpt and the most complex methods, to attach to a ticket, a code review or a wiki.

New goes back to the start screen and clears the analysis from memory. The files on your computer do not change.

AI prompts

The app shows where to look. You still need to understand why, decide on the fix and explain it to the team. An AI helps with these three tasks, but it is also confidently wrong: it invents system methods, mixes up Quit and Return and proposes code that does not compile. Treat the answer as a draft from a colleague in a hurry. To write better prompts, see the prompt tutorial.

Before pasting: code is company property and may contain passwords, addresses and business rules. The app sends nothing to the network, but the AI service receives everything you paste into it. Remove the secrets the app pointed out, replace customer names and follow your organization's policy on AI use.

Replace the parts in brackets and paste into the AI tool you use. Each prompt works on its own.

1. Prioritize the findings

In Report, use Copy, review the text and paste it at the end of the prompt.

You are a developer experienced in InterSystems IRIS and ObjectScript.
Below is the report of a tool that reads the code without compiling it.

Context: [what the system does and what you need to change]

Based only on the report:
1. Order the findings by real risk in this context and say why.
2. Point out those that may be false positives and what to check in the code to decide.
3. Suggest the order of the fixes, grouping what can go in the same change.
4. Separate what is in the report from what is your assumption.

Do not invent classes, methods or IRIS behaviors. If information is missing, say which.

Report:
[paste the report]

2. Explain a method

In the Flow tab, use See code and copy the method. In Member details, copy the Calls and Called by lists.

Explain the ObjectScript method below to someone who will maintain it.

Class: [class name and what it represents]
Who calls this method: [list]
What it calls: [list]

Code:
[paste the method]

Answer:
1. What the method does, in a few sentences.
2. The possible paths, including errors and early exits.
3. What it reads and writes: properties, globals, tables and transactions.
4. Fragile points, citing the line.

Remember that an argumentless Quit inside Try only leaves the Try block. If you do not know what a called method does, say so instead of guessing.

3. Fix a finding

Copy the name and explanation of the finding from the app and the code around the line. Ask for the smallest possible change.

The tool reported this finding in InterSystems IRIS ObjectScript code:

Finding: [name and explanation of the finding]
Line: [number]

Excerpt:
[paste the method or the lines around it]

1. Confirm whether the finding applies to this excerpt and explain why.
2. Propose the smallest possible fix, showing the code before and after.
3. Say what changes in behavior and what can break for the callers.
4. Say how to test the fix.

Use only features you know exist in IRIS. If you are not sure of the syntax, say so.

4. Split a complex method

Use the methods in the Most complex methods card. Ask it to keep the behavior, because replacing Quit with Return can change the flow. ^{[5] [6]}

The ObjectScript method below has complexity [number] and [number] lines.

[paste the method]

Propose a reorganization that:
1. Keeps exactly the same behavior, including the %Status return and the transactions.
2. Extracts parts with their own purpose into private methods with clear names.
3. Uses Return when the intent is to leave the method, and explains each change from Quit to Return.
4. Lists the test cases that prove nothing changed.

Show the full code. Do not rename public methods or change the signature.

5. Document a class

Useful for the Method without documentation finding. Check each sentence against the code: the AI may describe what the name suggests, not what the code does.

Write /// comments for the ObjectScript class below, in the style of the IRIS class reference.

[paste the class]

For the class and for each method:
1. One sentence about what it does.
2. The arguments and the return value.
3. Side effects: globals, tables, transactions and Lock.

Write in [language]. Describe only what the code shows. When it is not possible to know, write "check" instead of guessing.

6. Plan the tests

Ask for test cases based on the flowchart: each diamond has two sides to cover.

I want to test the ObjectScript method below before changing it.

[paste the method]

Test format used by the team: [e.g. %UnitTest.TestCase, or describe it]

1. List the paths of the method and one test case for each.
2. Include the error cases: error %Status, exception, SQLCODE other than 0.
3. Say what data must exist beforehand and how to clean it up afterwards.
4. Write the test code.

Do not use assertion methods you are not sure exist. If you need one, ask.

7. Modernize old code

For $ZTrap, %ResultSet and dot syntax. The class reference points to %SQL.Statement instead of %ResultSet. ^[11]

Modernize the ObjectScript code below without changing what it does.

[paste the code]

Replace, where present:
1. $ZTrap or $ETrap with Try/Catch.
2. %ResultSet with %SQL.Statement, using ? parameters instead of concatenation.
3. Dot syntax and line If with blocks in braces.

For each change, show before and after and explain the difference in behavior, if any. Point out what needs careful testing.

8. Describe the change for review

Use it after the fix: the AI organizes the text, and you check that each statement is true.

Write the description of a code review for the change below.

Problem found: [finding and place]
What was changed: [summary or diff]
How it was tested: [describe]

Structure:
1. Two-sentence summary.
2. Reason, with the finding and the line.
3. What changes for those who use the code.
4. Risks and how to revert.
5. What the reviewer should look at carefully.

Do not add tests, numbers or guarantees that are not here.

How to check the answer

Common mistakes and limitations

Reading mistakes

• Treating a finding as a defect. A Kill ^Global may be exactly what the method should do. Confirm in the code.
• Analyzing one class alone. Without the superclasses and the called classes, many links show up as "Outside the files".
• Looking for the cited line in the XML. In an XML export, the lines are those of the converted text, in the Code tab.
• Thinking low complexity means correct code. It measures paths, not correctness.

Limitations

• Reading without compiling. The app does not expand macros, does not resolve inheritance outside the files and can be wrong on rare constructs.
• Sample code only. The app was tested with the made-up sample and with excerpts written for the test, not with production code.
• Other languages. Methods in Python or another language have no flowchart. The app counts the lines and the iris.cls() calls.
• Size. Files over 30 MB are skipped. The map shows up to 180 nodes, and the members table up to 1,500 rows.
• Browsers. Tested in Chromium. Firefox, Safari and real phones were not tested.

Quick review

Try to answer before opening each question.

References

1. Giovani Perotto Mesquita, “IRIS Code Insights”, app in a single HTML file, giovanipm.github.io/iris-code-insights.html.
2. InterSystems, client-side workflow with the ObjectScript extension for VS Code, Export Code from Server command, documentation, accessed on 2 November 2026, docs.intersystems.com.
3. InterSystems, %SYSTEM.OBJ class, Export method, class reference, documentation, accessed on 2 November 2026, docs.intersystems.com.
4. InterSystems, TRY command, section on QUIT and RETURN, ObjectScript reference, documentation, accessed on 2 November 2026, docs.intersystems.com.
5. InterSystems, QUIT command, ObjectScript reference, documentation, accessed on 2 November 2026, docs.intersystems.com.
6. InterSystems, RETURN command, ObjectScript reference, documentation, accessed on 2 November 2026, docs.intersystems.com.
7. InterSystems, dynamic SQL, input parameters with ?, SQL guide, documentation, accessed on 2 November 2026, docs.intersystems.com.
8. InterSystems, SQLCODE values, SQL reference, documentation, accessed on 2 November 2026, docs.intersystems.com.
9. InterSystems, TROLLBACK command and $TLEVEL, ObjectScript reference, documentation, accessed on 2 November 2026, docs.intersystems.com.
10. InterSystems, LOCK command, timeout, ObjectScript reference, documentation, accessed on 2 November 2026, docs.intersystems.com.
11. InterSystems, %Library.ResultSet class, marked as deprecated, class reference, documentation, accessed on 2 November 2026, docs.intersystems.com.
12. InterSystems, system error messages, <FRAMESTACK>, documentation, accessed on 2 November 2026, docs.intersystems.com.
13. Thomas J. McCabe, “A Complexity Measure”, IEEE Transactions on Software Engineering, SE-2(4), 1976, pp. 308–320, doi.org/10.1109/TSE.1976.233837.

Che cos'è IRIS Code Insights

Prima di modificare una classe di InterSystems IRIS, arrivano quasi sempre le stesse domande: cosa fa questo codice, chi lo chiama e dove può rompersi? IRIS Code Insights legge classi e routine ObjectScript e risponde con tre viste: risultati ordinati per gravità, il diagramma di flusso di ogni metodo e una mappa di chi chiama chi. ^[1]

È un unico file HTML, senza installazione, senza account e senza server.

Apri IRIS Code Insights →

Come l'app tratta il tuo codice

• Niente esce dal tuo computer. Il file blocca le connessioni di rete, e la lettura avviene nel browser.
• Il codice non viene conservato. Chiudendo la pagina, l'analisi scompare. L'app salva solo la lingua e il tema.

Come portare il codice nell'app

L'app accetta quattro formati. Apri più file insieme: solo così può collegare la chiamata di una classe al metodo di un'altra.

Tre modi per ottenere i file

1. VS Code: con l'estensione InterSystems ObjectScript, usa il comando ObjectScript: Export Code from Server. Per impostazione predefinita, i file vanno nella cartella src del workspace. ^[2]
2. Terminal di IRIS: il metodo Export della classe %SYSTEM.OBJ crea un XML con gli elementi richiesti, come classi e routine. ^[3]

Do $SYSTEM.OBJ.Export("Demo.*.cls","/tmp/demo.xml")

3. Incollare: in Incolla codice, incolla una classe, una routine o un XML. Il nome del file è facoltativo: senza nome, l'app riconosce il tipo dal contenuto.

Percorso: analizzare l'esempio

Usa l'esempio dell'app: quattro file fittizi, scritti per mostrare i risultati. C'è una classe persistente di ordini, un'API REST, un business service e una vecchia routine. Quello che segue è esattamente ciò che vedrai.

1. Apri l'esempio e leggi gli indicatori

1. Apri l'app e fai clic su Vedi un esempio.
2. Controlla in alto: 4 file, 3 classi e 1 routine, 15 metodi ed etichette, 197 righe, complessità media 2,3 (massima 6), 60% dei metodi documentati e 3 risultati critici, con 11 da verificare.
3. I filtri mostrano 18 tipi di risultato: 3 critici, 8 di attenzione e 7 di informazione.

2. Dal risultato alla riga

1. Nel risultato Kill cancella un'intera globale, fai clic su Vedi dove (1).
2. Fai clic su Order.Purge. La scheda Codice si apre alla riga 85, evidenziata: Kill ^DemoAudit.
3. Guarda la riga 79: Kill ^DemoAudit(id) cancella un solo nodo e non genera un risultato. La differenza è l'indice.

3. Leggi il flusso di un metodo

1. Apri la scheda Flusso e scegli Pay nell'elenco a sinistra.
2. Il corpo sta dentro un riquadro Try, collegato al riquadro Catch ex da una freccia rossa tratteggiata: il percorso dell'errore.
3. Il rombo order.Status '= "NEW" ? porta a un Quit con bordo rosso e la nota esce dal blocco corrente.

Perché il bordo rosso? Secondo la documentazione, un Quit senza argomento dentro un Try porta l'esecuzione alla prima riga dopo il Catch, non fuori dal metodo. ^[4] Qui la riga successiva è Quit sc, quindi l'effetto è quello atteso. Ma se qualcuno aggiunge codice dopo il Catch, verrà eseguito anche per gli ordini che non sono nuovi. Return renderebbe esplicita l'intenzione. ^[6]

Nello stesso metodo ci sono altri tre risultati: Do order.%Save() scarta il %Status, l'&sql non controlla SQLCODE e il TStart non ha un TRollback nel Catch.

4. Guarda chi chiama chi

1. Apri la scheda Dipendenze e fai clic su Metodi.
2. Fai clic sul nodo PayOrder. Il percorso viene evidenziato: la rotta POST /orders/:id/pay arriva a lui, e lui chiama Notify, Pay e Sync.Send.

5. Controlla i dati usati

La scheda Dati mostra due tabelle SQL e quattro globali. La globale ^DemoAudit viene letta, scritta, cancellata con Kill e bloccata con Lock, in 8 usi. Compaiono anche la rotta REST e il messaggio per Demo.ERP.Operation. Questa classe di destinazione non è nei file.

6. Genera il report

1. Fai clic su Report.
2. Rivedi il testo e usa Copia o Scarica .md.

Risultato: in pochi minuti sai da dove cominciare. C'è una password nel codice, un SQL esposto all'injection e un Kill che cancella l'intero audit. Sai anche quali metodi e tabelle tocca ogni correzione.

Come leggere gli insight

Ogni risultato è una regola semplice sul testo del codice, e queste sono le condizioni esatte. Un risultato dice dove guardare, non che c'è un difetto.

Critico

Attenzione

Informazione

• %ResultSet è deprecato: il riferimento delle classi indica %Library.ResultSet come deprecato e %SQL.Statement per l'SQL dinamico. La classe funziona ancora. ^[11]
• $ZTrap o $ETrap, Goto, privato e non usato nei file, metodo senza documentazione ///, indirizzo o percorso fisso (URL, IP o cartella) e classe che accede direttamente a una globale.
• Chiamata ricorsiva: senza condizione di arresto, le chiamate si accumulano fino all'errore <FRAMESTACK>, che indica troppe chiamate annidate. ^[12]
• Parte che l'app non ha capito: il diagramma e i risultati di quel membro possono essere incompleti.

Indicatori e complessità

La complessità segue l'idea di McCabe: quanti percorsi indipendenti ha un metodo. ^[13] L'app usa un'approssimazione: 1, più ogni If, ElseIf, ciclo, Catch e postcondizionale. Serve a confrontare i metodi tra loro. "Metodi documentati" conta i metodi di classe con commento ///. Sotto l'elenco, Verifiche senza risultati mostra cosa è stato cercato e non trovato.

Flusso

La scheda Flusso disegna un metodo o un'etichetta alla volta, a partire dai comandi del codice. Scegli il metodo nell'elenco: il numero accanto al nome è la complessità. I metodi con più percorsi mostrano il numero in arancione o rosso.

• Raggruppa i comandi semplici unisce comandi consecutivi come Set, Kill e New in un solo blocco. Deselezionalo per vedere un blocco per comando.
• Fai clic su un blocco per vedere il comando intero, la riga e i risultati. Vedi codice apre la riga. Un doppio clic su una chiamata apre il flusso del metodo chiamato.
• Trascina lo sfondo per spostarti, usa i pulsanti di zoom o Adatta, e Scarica SVG per salvare la figura.
• Sotto il disegno, Dettagli del membro mostra la dichiarazione, la documentazione, cosa chiama, chi lo chiama e i dati che usa.

Dipendenze

La scheda Dipendenze mostra la mappa di chi chiama chi. Le colonne seguono la direzione delle chiamate: chi chiama sta a sinistra. Più la linea è spessa, più chiamate ci sono.

• Classi raggruppa tutto per classe o routine e mostra l'ereditarietà con una linea viola tratteggiata. Metodi mostra ogni metodo, le rotte REST che arrivano a lui e le destinazioni dei messaggi.
• Esterni, Tabelle e Globali attivano e disattivano quei nodi. "Fuori dai file" è una classe o routine citata che non hai caricato.
• Una linea che torna a sinistra, a trattini corti, chiude un ciclo di chiamate.
• Fai clic su un nodo per evidenziarne i collegamenti. Il pannello a destra elenca cosa esce e cosa arriva, con scorciatoie al flusso e al codice.

Membri, Dati e Codice

• Membri: la tabella di tutti i membri, con tipo, righe, complessità, annidamento, documentazione e chiamate. Fai clic sul titolo di una colonna per ordinare e usa il filtro e il tipo per ridurre l'elenco.
• Dati: le tabelle SQL, con le operazioni e la forma (&sql, SQL dinamico o Query della classe), e le globali, con il tipo di accesso: lettura, scrittura, Kill o Lock. La classe viene collegata alla tabella con il nome SQL predefinito: il pacchetto con _ al posto del punto, più il nome della classe, oppure con SqlTableName. Le rotte REST vengono da XData UrlMap, e i messaggi da SendRequestSync, SendRequestAsync e dai <call target> di una BPL.
• Codice: il file con l'evidenziazione della sintassi. Scegli il file, scrivi il numero in riga e fai clic su Vai.
• Ricerca: il campo in alto trova classi, metodi ed etichette in tutti i file.

Report e privacy

Report genera un testo in Markdown con il riepilogo, i risultati, i punti con l'estratto del codice e i metodi più complessi, da allegare a un ticket, a una revisione del codice o a una wiki.

Nuovo torna alla schermata iniziale e toglie l'analisi dalla memoria. I file sul tuo computer non cambiano.

Prompt per l'IA

L'app mostra dove guardare. Resta da capire il perché, decidere la correzione e spiegarla al team. Un'IA aiuta in questi tre compiti, ma sbaglia anche con sicurezza: inventa metodi di sistema, confonde Quit e Return e propone codice che non compila. Tratta la risposta come la bozza di un collega di fretta. Per scrivere prompt migliori, vedi il tutorial sui prompt.

Prima di incollare: il codice è proprietà dell'azienda e può contenere password, indirizzi e regole di business. L'app non invia nulla in rete, ma il servizio di IA riceve tutto ciò che incolli. Togli i segreti che l'app ha segnalato, sostituisci i nomi dei clienti e segui la politica della tua organizzazione sull'uso dell'IA.

Sostituisci le parti tra parentesi quadre e incolla nello strumento di IA che usi. Ogni prompt funziona da solo.

1. Dare priorità ai risultati

In Report, usa Copia, rivedi il testo e incollalo alla fine del prompt.

Sei uno sviluppatore esperto di InterSystems IRIS e ObjectScript.
Qui sotto c'è il report di uno strumento che legge il codice senza compilarlo.

Contesto: [cosa fa il sistema e cosa devi modificare]

Basandoti solo sul report:
1. Ordina i risultati per rischio reale in questo contesto e spiega perché.
2. Indica quelli che possono essere falsi positivi e cosa controllare nel codice per decidere.
3. Suggerisci l'ordine delle correzioni, raggruppando ciò che può andare nella stessa modifica.
4. Separa ciò che è nel report da ciò che è una tua supposizione.

Non inventare classi, metodi o comportamenti di IRIS. Se manca un'informazione, di' quale.

Report:
[incolla il report]

2. Spiegare un metodo

Nella scheda Flusso, usa Vedi codice e copia il metodo. In Dettagli del membro, copia gli elenchi Chiama e Chiamato da.

Spiega il metodo ObjectScript qui sotto a chi dovrà mantenerlo.

Classe: [nome della classe e cosa rappresenta]
Chi chiama questo metodo: [elenco]
Cosa chiama: [elenco]

Codice:
[incolla il metodo]

Rispondi:
1. Cosa fa il metodo, in poche frasi.
2. I percorsi possibili, compresi errori e uscite anticipate.
3. Cosa legge e scrive: proprietà, globali, tabelle e transazioni.
4. Punti fragili, citando la riga.

Ricorda che un Quit senza argomento dentro un Try esce solo dal blocco Try. Se non sai cosa fa un metodo chiamato, dillo invece di supporlo.

3. Correggere un risultato

Copia dall'app il nome e la spiegazione del risultato e il codice intorno alla riga. Chiedi la modifica più piccola possibile.

Lo strumento ha segnalato questo risultato in un codice ObjectScript di InterSystems IRIS:

Risultato: [nome e spiegazione del risultato]
Riga: [numero]

Estratto:
[incolla il metodo o le righe intorno]

1. Conferma se il risultato vale per questo estratto e spiega perché.
2. Proponi la correzione più piccola possibile, mostrando il codice prima e dopo.
3. Di' cosa cambia nel comportamento e cosa può rompersi per i chiamanti.
4. Di' come testare la correzione.

Usa solo funzionalità che sai che esistono in IRIS. Se non sei sicuro della sintassi, avvisa.

4. Dividere un metodo complesso

Usa i metodi della scheda Metodi più complessi. Chiedi di mantenere il comportamento, perché sostituire Quit con Return può cambiare il flusso. ^{[5] [6]}

Il metodo ObjectScript qui sotto ha complessità [numero] e [numero] righe.

[incolla il metodo]

Proponi una riorganizzazione che:
1. Mantenga esattamente lo stesso comportamento, compreso il ritorno di %Status e le transazioni.
2. Estragga le parti con uno scopo proprio in metodi privati con nomi chiari.
3. Usi Return quando l'intenzione è uscire dal metodo, spiegando ogni sostituzione di Quit con Return.
4. Elenchi i casi di test che provano che nulla è cambiato.

Mostra il codice completo. Non rinominare metodi pubblici né cambiare la firma.

5. Documentare una classe

Utile per il risultato Metodo senza documentazione. Confronta ogni frase con il codice: l'IA può descrivere ciò che il nome suggerisce, non ciò che il codice fa.

Scrivi commenti /// per la classe ObjectScript qui sotto, nello stile del riferimento delle classi di IRIS.

[incolla la classe]

Per la classe e per ogni metodo:
1. Una frase su cosa fa.
2. Gli argomenti e il valore restituito.
3. Effetti collaterali: globali, tabelle, transazioni e Lock.

Scrivi in [lingua]. Descrivi solo ciò che il codice mostra. Quando non si può sapere, scrivi "verificare" invece di supporre.

6. Pianificare i test

Chiedi casi di test a partire dal diagramma: ogni rombo ha due lati da coprire.

Voglio testare il metodo ObjectScript qui sotto prima di modificarlo.

[incolla il metodo]

Formato di test usato dal team: [es.: %UnitTest.TestCase, o descrivilo]

1. Elenca i percorsi del metodo e un caso di test per ognuno.
2. Includi i casi di errore: %Status di errore, eccezione, SQLCODE diverso da 0.
3. Di' quali dati devono esistere prima e come ripulirli dopo.
4. Scrivi il codice dei test.

Non usare metodi di asserzione di cui non sei sicuro. Se te ne serve uno, chiedi.

7. Modernizzare codice vecchio

Serve per $ZTrap, %ResultSet e la sintassi a punti. Il riferimento delle classi indica %SQL.Statement al posto di %ResultSet. ^[11]

Modernizza il codice ObjectScript qui sotto, senza cambiare ciò che fa.

[incolla il codice]

Sostituisci, dove presente:
1. $ZTrap o $ETrap con Try/Catch.
2. %ResultSet con %SQL.Statement, con parametri ? invece della concatenazione.
3. Sintassi a punti e If di riga con blocchi tra graffe.

Per ogni sostituzione, mostra prima e dopo e spiega la differenza di comportamento, se c'è. Indica cosa va testato con attenzione.

8. Descrivere la modifica per la revisione

Da usare dopo la correzione: l'IA organizza il testo, e tu verifichi che ogni affermazione sia vera.

Scrivi la descrizione di una revisione del codice per la modifica qui sotto.

Problema trovato: [risultato e punto]
Cosa è stato modificato: [riepilogo o diff]
Come è stato testato: [descrivi]

Struttura:
1. Riepilogo in due frasi.
2. Motivo, con il risultato e la riga.
3. Cosa cambia per chi usa il codice.
4. Rischi e come annullare la modifica.
5. Cosa il revisore deve guardare con attenzione.

Non aggiungere test, numeri o garanzie che non sono qui.

Come verificare la risposta

Errori comuni e limiti

Errori di lettura

• Trattare un risultato come un difetto. Un Kill ^Global può essere esattamente ciò che il metodo deve fare. Verifica nel codice.
• Analizzare una classe da sola. Senza le superclassi e le classi chiamate, molti collegamenti compaiono come "Fuori dai file".
• Cercare nell'XML la riga citata. Nell'esportazione XML, le righe sono quelle del testo convertito, nella scheda Codice.
• Pensare che complessità bassa significhi codice corretto. Misura i percorsi, non la correttezza.

Limiti

• Lettura senza compilare. L'app non espande le macro, non risolve l'ereditarietà fuori dai file e può sbagliare su costrutti rari.
• Solo codice di esempio. L'app è stata testata con l'esempio fittizio e con estratti scritti per il test, non con codice di produzione.
• Altri linguaggi. I metodi in Python o in un altro linguaggio non hanno diagramma. L'app conta le righe e le chiamate iris.cls().
• Dimensioni. I file sopra i 30 MB vengono ignorati. La mappa mostra fino a 180 nodi, e la tabella dei membri fino a 1.500 righe.
• Browser. Testato in Chromium. Firefox, Safari e telefoni reali non sono stati testati.

Ripasso rapido

Prova a rispondere prima di aprire ogni domanda.

Riferimenti

1. Giovani Perotto Mesquita, “IRIS Code Insights”, app in un unico file HTML, giovanipm.github.io/iris-code-insights.html.
2. InterSystems, flusso di lavoro lato client con l'estensione ObjectScript per VS Code, comando Export Code from Server, documentazione, consultato il 02/11/2026, docs.intersystems.com.
3. InterSystems, classe %SYSTEM.OBJ, metodo Export, riferimento delle classi, documentazione, consultato il 02/11/2026, docs.intersystems.com.
4. InterSystems, comando TRY, sezione su QUIT e RETURN, riferimento di ObjectScript, documentazione, consultato il 02/11/2026, docs.intersystems.com.
5. InterSystems, comando QUIT, riferimento di ObjectScript, documentazione, consultato il 02/11/2026, docs.intersystems.com.
6. InterSystems, comando RETURN, riferimento di ObjectScript, documentazione, consultato il 02/11/2026, docs.intersystems.com.
7. InterSystems, SQL dinamico, parametri di input con ?, guida SQL, documentazione, consultato il 02/11/2026, docs.intersystems.com.
8. InterSystems, valori di SQLCODE, riferimento SQL, documentazione, consultato il 02/11/2026, docs.intersystems.com.
9. InterSystems, comando TROLLBACK e $TLEVEL, riferimento di ObjectScript, documentazione, consultato il 02/11/2026, docs.intersystems.com.
10. InterSystems, comando LOCK, timeout, riferimento di ObjectScript, documentazione, consultato il 02/11/2026, docs.intersystems.com.
11. InterSystems, classe %Library.ResultSet, indicata come deprecata, riferimento delle classi, documentazione, consultato il 02/11/2026, docs.intersystems.com.
12. InterSystems, messaggi di errore di sistema, <FRAMESTACK>, documentazione, consultato il 02/11/2026, docs.intersystems.com.
13. Thomas J. McCabe, “A Complexity Measure”, IEEE Transactions on Software Engineering, SE-2(4), 1976, pp. 308–320, doi.org/10.1109/TSE.1976.233837.

Qué es IRIS Code Insights

Antes de cambiar una clase de InterSystems IRIS, casi siempre surgen las mismas preguntas: qué hace este código, quién lo llama y dónde puede romperse. IRIS Code Insights lee clases y rutinas ObjectScript y responde con tres vistas: hallazgos ordenados por gravedad, el diagrama de flujo de cada método y un mapa de quién llama a quién. ^[1]

Es un único archivo HTML, sin instalación, sin cuenta y sin servidor.

Abrir IRIS Code Insights →

Cómo trata la app tu código

• Nada sale de tu equipo. El archivo bloquea las conexiones de red, y la lectura ocurre en el navegador.
• El código no se guarda. Al cerrar la página, el análisis desaparece. La app solo guarda el idioma y el tema.

Cómo llevar el código a la app

La app acepta cuatro formatos. Abre varios archivos juntos: solo así puede enlazar la llamada de una clase con el método de otra.

Tres formas de obtener los archivos

1. VS Code: con la extensión InterSystems ObjectScript, usa el comando ObjectScript: Export Code from Server. De forma predeterminada, los archivos van a la carpeta src del workspace. ^[2]
2. Terminal de IRIS: el método Export de la clase %SYSTEM.OBJ genera un XML con los elementos pedidos, como clases y rutinas. ^[3]

Do $SYSTEM.OBJ.Export("Demo.*.cls","/tmp/demo.xml")

3. Pegar: en Pegar código, pega una clase, una rutina o un XML. El nombre del archivo es opcional: sin él, la app reconoce el tipo por el contenido.

Guía: analizando el ejemplo

Usa el ejemplo de la propia app: cuatro archivos ficticios, escritos para mostrar los hallazgos. Hay una clase persistente de pedidos, una API REST, un business service y una rutina antigua. Lo que sigue es exactamente lo que verás.

1. Abre el ejemplo y lee los indicadores

1. Abre la app y haz clic en Ver un ejemplo.
2. Revisa la parte superior: 4 archivos, 3 clases y 1 rutina, 15 métodos y etiquetas, 197 líneas, complejidad media 2,3 (máxima 6), 60% de los métodos documentados y 3 hallazgos críticos, con 11 de atención.
3. Los filtros muestran 18 tipos de hallazgo: 3 críticos, 8 de atención y 7 de información.

2. Del hallazgo a la línea

1. En el hallazgo Kill borra una global entera, haz clic en Ver dónde (1).
2. Haz clic en Order.Purge. La pestaña Código se abre en la línea 85, destacada: Kill ^DemoAudit.
3. Fíjate en la línea 79: Kill ^DemoAudit(id) borra solo un nodo y no genera hallazgo. La diferencia es el subíndice.

3. Lee el flujo de un método

1. Abre la pestaña Flujo y elige Pay en la lista de la izquierda.
2. El cuerpo está dentro de un cuadro Try, unido al cuadro Catch ex por una flecha roja discontinua: el camino del error.
3. El rombo order.Status '= "NEW" ? lleva a un Quit con borde rojo y la nota sale del bloque actual.

¿Por qué el borde rojo? Según la documentación, un Quit sin argumento dentro de un Try lleva la ejecución a la primera línea después del Catch, y no fuera del método. ^[4] Aquí la línea siguiente es Quit sc, así que el efecto es el esperado. Pero, si alguien añade código después del Catch, también se ejecutará para los pedidos que no son nuevos. Return dejaría clara la intención. ^[6]

En el mismo método aparecen tres hallazgos más: Do order.%Save() descarta el %Status, el &sql no comprueba SQLCODE y el TStart no tiene TRollback en el Catch.

4. Mira quién llama a quién

1. Abre la pestaña Dependencias y haz clic en Métodos.
2. Haz clic en el nodo PayOrder. El camino queda destacado: la ruta POST /orders/:id/pay llega a él, y él llama a Notify, Pay y Sync.Send.

5. Revisa los datos usados

La pestaña Datos muestra dos tablas SQL y cuatro globales. La global ^DemoAudit se lee, se escribe, se borra con Kill y se bloquea con Lock, en 8 usos. También aparecen la ruta REST y el mensaje para Demo.ERP.Operation. Esa clase de destino no está en los archivos.

6. Genera el informe

1. Haz clic en Informe.
2. Revisa el texto y usa Copiar o Descargar .md.

Resultado: en pocos minutos sabes por dónde empezar. Hay una contraseña en el código, un SQL vulnerable a inyección y un Kill que borra toda la auditoría. También sabes qué métodos y tablas afecta cada corrección.

Cómo leer los insights

Cada hallazgo es una regla simple sobre el texto del código, y estas son las condiciones exactas. Un hallazgo dice dónde mirar, no que haya un defecto.

Crítico

Atención

Información

• %ResultSet está obsoleto: la referencia de clases marca %Library.ResultSet como obsoleta e indica %SQL.Statement para SQL dinámico. La clase sigue funcionando. ^[11]
• $ZTrap o $ETrap, Goto, privado sin uso en los archivos, método sin documentación ///, dirección o ruta fija (URL, IP o carpeta) y clase que accede a una global directamente.
• Llamada recursiva: sin condición de parada, las llamadas se acumulan hasta el error <FRAMESTACK>, que indica demasiadas llamadas anidadas. ^[12]
• Parte que la app no entendió: el diagrama y los hallazgos de ese miembro pueden estar incompletos.

Indicadores y complejidad

La complejidad sigue la idea de McCabe: cuántos caminos independientes tiene un método. ^[13] La app usa una aproximación: 1, más cada If, ElseIf, bucle, Catch y poscondicional. Sirve para comparar métodos entre sí. "Métodos documentados" cuenta los métodos de clase con comentario ///. Debajo de la lista, Verificaciones sin hallazgos muestra lo que se buscó y no se encontró.

Flujo

La pestaña Flujo dibuja un método o etiqueta cada vez, a partir de los comandos del código. Elige el método en la lista: el número junto al nombre es la complejidad. Los métodos con más caminos muestran el número en naranja o rojo.

• Agrupar comandos simples junta comandos seguidos como Set, Kill y New en un solo bloque. Desmárcalo para ver un bloque por comando.
• Haz clic en un bloque para ver el comando completo, la línea y los hallazgos. Ver código abre la línea. Doble clic en una llamada abre el flujo del método llamado.
• Arrastra el fondo para moverte, usa los botones de zoom o Ajustar, y Descargar SVG para guardar la figura.
• Debajo del dibujo, Detalles del miembro muestra la declaración, la documentación, a quién llama, quién lo llama y los datos que usa.

Dependencias

La pestaña Dependencias muestra el mapa de quién llama a quién. Las columnas siguen la dirección de las llamadas: quien llama queda a la izquierda. Cuanto más gruesa la línea, más llamadas.

• Clases agrupa todo por clase o rutina y muestra la herencia con una línea morada discontinua. Métodos muestra cada método, las rutas REST que llegan a él y los destinos de mensajes.
• Externos, Tablas y Globales muestran u ocultan esos nodos. "Fuera de los archivos" es una clase o rutina citada que no cargaste.
• Una línea que vuelve hacia la izquierda, con trazos cortos, cierra un ciclo de llamadas.
• Haz clic en un nodo para destacar sus enlaces. El panel de la derecha lista lo que sale y lo que llega, con atajos al flujo y al código.

Miembros, Datos y Código

• Miembros: la tabla de todos los miembros, con tipo, líneas, complejidad, anidamiento, documentación y llamadas. Haz clic en el título de una columna para ordenar y usa el filtro y el tipo para acortar la lista.
• Datos: las tablas SQL, con las operaciones y la forma (&sql, SQL dinámico o Query de la clase), y las globales, con el tipo de acceso: lectura, escritura, Kill o Lock. La clase se enlaza a la tabla por el nombre SQL predeterminado: el paquete con _ en lugar del punto, más el nombre de la clase, o por el SqlTableName. Las rutas REST vienen del XData UrlMap, y los mensajes, de SendRequestSync, SendRequestAsync y de los <call target> de una BPL.
• Código: el archivo con resaltado de sintaxis. Elige el archivo, escribe el número en línea y haz clic en Ir.
• Búsqueda: el campo de arriba encuentra clases, métodos y etiquetas en todos los archivos.

Informe y privacidad

Informe genera un texto en Markdown con el resumen, los hallazgos, los lugares con el fragmento del código y los métodos más complejos, para adjuntar a un ticket, a una revisión de código o a una wiki.

Nuevo vuelve a la pantalla inicial y saca el análisis de la memoria. Los archivos de tu equipo no cambian.

Prompts de IA

La app muestra dónde mirar. Falta entender el porqué, decidir la corrección y explicarla al equipo. Una IA ayuda en esas tres tareas, pero también se equivoca con seguridad: inventa métodos del sistema, confunde Quit con Return y propone código que no compila. Trata la respuesta como el borrador de un colega con prisa. Para escribir mejores prompts, consulta el tutorial de prompts.

Antes de pegar: el código es propiedad de la empresa y puede traer contraseñas, direcciones y reglas de negocio. La app no envía nada a la red, pero el servicio de IA recibe todo lo que pegues en él. Quita los secretos que la app señaló, cambia los nombres de clientes y sigue la política de tu organización sobre el uso de IA.

Cambia las partes entre corchetes y pega en la herramienta de IA que uses. Cada prompt funciona por sí solo.

1. Priorizar los hallazgos

En Informe, usa Copiar, revisa el texto y pégalo al final del prompt.

Eres un desarrollador con experiencia en InterSystems IRIS y ObjectScript.
Abajo está el informe de una herramienta que lee el código sin compilarlo.

Contexto: [qué hace el sistema y qué necesitas cambiar]

Basándote solo en el informe:
1. Ordena los hallazgos por riesgo real en este contexto y explica por qué.
2. Señala los que pueden ser falsos positivos y qué revisar en el código para decidir.
3. Sugiere el orden de las correcciones, agrupando lo que puede ir en el mismo cambio.
4. Separa lo que está en el informe de lo que es suposición tuya.

No inventes clases, métodos ni comportamientos de IRIS. Si falta información, di cuál.

Informe:
[pega el informe]

2. Explicar un método

En la pestaña Flujo, usa Ver código y copia el método. En Detalles del miembro, copia las listas Llama y Llamado por.

Explica el método ObjectScript de abajo a alguien que va a mantenerlo.

Clase: [nombre de la clase y qué representa]
Quién llama a este método: [lista]
A quién llama: [lista]

Código:
[pega el método]

Responde:
1. Qué hace el método, en pocas frases.
2. Los caminos posibles, incluidos errores y salidas anticipadas.
3. Qué lee y escribe: propiedades, globales, tablas y transacciones.
4. Puntos frágiles, citando la línea.

Recuerda que un Quit sin argumento dentro de Try solo sale del bloque Try. Si no sabes qué hace un método llamado, dilo en lugar de suponer.

3. Corregir un hallazgo

Copia de la app el nombre y la explicación del hallazgo y el código alrededor de la línea. Pide el cambio más pequeño posible.

La herramienta señaló este hallazgo en un código ObjectScript de InterSystems IRIS:

Hallazgo: [nombre y explicación del hallazgo]
Línea: [número]

Fragmento:
[pega el método o las líneas alrededor]

1. Confirma si el hallazgo aplica a este fragmento y explica por qué.
2. Propón la corrección más pequeña posible, mostrando el código antes y después.
3. Di qué cambia en el comportamiento y qué puede romperse para quien llama.
4. Di cómo probar la corrección.

Usa solo recursos que sepas que existen en IRIS. Si no estás seguro de la sintaxis, avisa.

4. Dividir un método complejo

Usa los métodos de la tarjeta Métodos más complejos. Pide mantener el comportamiento, porque cambiar Quit por Return puede alterar el flujo. ^{[5] [6]}

El método ObjectScript de abajo tiene complejidad [número] y [número] líneas.

[pega el método]

Propón una reorganización que:
1. Mantenga exactamente el mismo comportamiento, incluido el retorno de %Status y las transacciones.
2. Extraiga partes con propósito propio a métodos privados con nombres claros.
3. Use Return cuando la intención sea salir del método, y explique cada cambio de Quit por Return.
4. Liste los casos de prueba que demuestran que nada cambió.

Muestra el código completo. No renombres métodos públicos ni cambies la firma.

5. Documentar una clase

Útil para el hallazgo Método sin documentación. Compara cada frase con el código: la IA puede describir lo que sugiere el nombre y no lo que hace el código.

Escribe comentarios /// para la clase ObjectScript de abajo, al estilo de la referencia de clases de IRIS.

[pega la clase]

Para la clase y para cada método:
1. Una frase sobre lo que hace.
2. Los argumentos y el retorno.
3. Efectos secundarios: globales, tablas, transacciones y Lock.

Escribe en [idioma]. Describe solo lo que muestra el código. Cuando no se pueda saber, escribe "verificar" en lugar de suponer.

6. Planificar las pruebas

Pide casos de prueba a partir del diagrama: cada rombo tiene dos lados que cubrir.

Quiero probar el método ObjectScript de abajo antes de cambiarlo.

[pega el método]

Formato de prueba que usa el equipo: [p. ej.: %UnitTest.TestCase, o descríbelo]

1. Lista los caminos del método y un caso de prueba para cada uno.
2. Incluye los casos de error: %Status de error, excepción, SQLCODE distinto de 0.
3. Di qué datos deben existir antes y cómo limpiarlos después.
4. Escribe el código de las pruebas.

No uses métodos de aserción de los que no estés seguro. Si necesitas uno, pregunta.

7. Modernizar código antiguo

Sirve para $ZTrap, %ResultSet y la sintaxis de puntos. La referencia de clases indica %SQL.Statement en lugar de %ResultSet. ^[11]

Moderniza el código ObjectScript de abajo, sin cambiar lo que hace.

[pega el código]

Cambia, cuando haya:
1. $ZTrap o $ETrap por Try/Catch.
2. %ResultSet por %SQL.Statement, con parámetros ? en lugar de concatenación.
3. Sintaxis de puntos e If de línea por bloques con llaves.

Para cada cambio, muestra antes y después y explica la diferencia de comportamiento, si la hay. Señala lo que hay que probar con cuidado.

8. Describir el cambio para la revisión

Úsalo después de corregir: la IA organiza el texto, y tú compruebas que cada afirmación sea verdadera.

Escribe la descripción de una revisión de código para el cambio de abajo.

Problema encontrado: [hallazgo y lugar]
Qué se cambió: [resumen o diff]
Cómo se probó: [describe]

Estructura:
1. Resumen en dos frases.
2. Motivo, con el hallazgo y la línea.
3. Qué cambia para quien usa el código.
4. Riesgos y cómo revertir.
5. Qué debe mirar con atención quien revisa.

No añadas pruebas, números ni garantías que no estén aquí.

Cómo comprobar la respuesta

Errores comunes y limitaciones

Errores de lectura

• Tratar un hallazgo como un defecto. Un Kill ^Global puede ser justo lo que el método debe hacer. Confírmalo en el código.
• Analizar una clase sola. Sin las superclases y las clases llamadas, muchos enlaces aparecen como "Fuera de los archivos".
• Buscar en el XML la línea citada. En la exportación XML, las líneas son las del texto convertido, en la pestaña Código.
• Creer que complejidad baja es código correcto. Mide caminos, no corrección.

Limitaciones

• Lectura sin compilar. La app no expande macros, no resuelve la herencia fuera de los archivos y puede equivocarse en construcciones raras.
• Solo código de ejemplo. La app se probó con el ejemplo ficticio y con fragmentos escritos para la prueba, no con código de producción.
• Otros lenguajes. Los métodos en Python u otro lenguaje no tienen diagrama. La app cuenta las líneas y las llamadas iris.cls().
• Tamaño. Los archivos de más de 30 MB se ignoran. El mapa muestra hasta 180 nodos, y la tabla de miembros, hasta 1.500 filas.
• Navegadores. Probado en Chromium. Firefox, Safari y móviles reales no se probaron.

Repaso rápido

Intenta responder antes de abrir cada pregunta.

Referencias

1. Giovani Perotto Mesquita, “IRIS Code Insights”, app en un único archivo HTML, giovanipm.github.io/iris-code-insights.html.
2. InterSystems, flujo de trabajo en el cliente con la extensión ObjectScript para VS Code, comando Export Code from Server, documentación, consultado el 02/11/2026, docs.intersystems.com.
3. InterSystems, clase %SYSTEM.OBJ, método Export, referencia de clases, documentación, consultado el 02/11/2026, docs.intersystems.com.
4. InterSystems, comando TRY, sección sobre QUIT y RETURN, referencia de ObjectScript, documentación, consultado el 02/11/2026, docs.intersystems.com.
5. InterSystems, comando QUIT, referencia de ObjectScript, documentación, consultado el 02/11/2026, docs.intersystems.com.
6. InterSystems, comando RETURN, referencia de ObjectScript, documentación, consultado el 02/11/2026, docs.intersystems.com.
7. InterSystems, SQL dinámico, parámetros de entrada con ?, guía de SQL, documentación, consultado el 02/11/2026, docs.intersystems.com.
8. InterSystems, valores de SQLCODE, referencia de SQL, documentación, consultado el 02/11/2026, docs.intersystems.com.
9. InterSystems, comando TROLLBACK y $TLEVEL, referencia de ObjectScript, documentación, consultado el 02/11/2026, docs.intersystems.com.
10. InterSystems, comando LOCK, tiempo límite, referencia de ObjectScript, documentación, consultado el 02/11/2026, docs.intersystems.com.
11. InterSystems, clase %Library.ResultSet, marcada como obsoleta, referencia de clases, documentación, consultado el 02/11/2026, docs.intersystems.com.
12. InterSystems, mensajes de error del sistema, <FRAMESTACK>, documentación, consultado el 02/11/2026, docs.intersystems.com.
13. Thomas J. McCabe, “A Complexity Measure”, IEEE Transactions on Software Engineering, SE-2(4), 1976, pp. 308–320, doi.org/10.1109/TSE.1976.233837.